Odpowiedź 400 vs 422 na test POST danych

355

Usiłuję dowiedzieć się, jaki poprawny kod stanu zwraca w różnych scenariuszach za pomocą interfejsu API typu „REST”, nad którym pracuję. Powiedzmy, że mam punkt końcowy, który pozwala na dokonywanie zakupów POST w formacie JSON. To wygląda tak:

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

Co mam zwrócić, jeśli klient wyśle ​​mi „sales_tax” (zamiast oczekiwanego „podatku”). Obecnie zwracam 400. Ale zacząłem zadawać sobie pytania na ten temat. Czy naprawdę powinienem zwrócić 422? Mam na myśli, że jest to JSON (który jest obsługiwany) i jest prawidłowy JSON, po prostu nie zawiera wszystkich wymaganych pól.

David S.
źródło
1
możliwy duplikat REST: mapowanie błędów aplikacji na kody stanu HTTP
Anirudh Ramanathan

Odpowiedzi:

419

400 Błędne żądanie wydaje się teraz najlepszym kodem statusu HTTP / 1.1 dla twojego przypadku użycia.

W momencie twojego pytania (i mojej pierwotnej odpowiedzi) RFC 7231 nie było rzeczą; w którym momencie sprzeciwiłem się, 400 Bad Requestponieważ RFC 2616 powiedział (z naciskiem mój):

Serwer nie mógł zrozumieć żądania z powodu nieprawidłowej składni .

a opisywane przez ciebie żądanie jest poprawnym składniowo JSON zamkniętym w poprawnym składniowo HTTP, a zatem serwer nie ma problemów ze składnią żądania.

Jednak, jak wskazał Lee Saferite w komentarzach , RFC 7231, która przestarza RFC 2616, nie obejmuje tego ograniczenia :

Kod statusu 400 (Błędne żądanie) wskazuje, że serwer nie może lub nie przetworzy żądania z powodu czegoś, co jest postrzegane jako błąd klienta (np. Źle sformułowana składnia żądania, nieprawidłowe sformułowanie komunikatu żądania lub oszukańczy routing żądania).


Jednak przed tym ponownym sformułowaniem (lub jeśli chcesz spierać się o to, że RFC 7231 jest obecnie tylko proponowanym standardem), 422 Unprocessable Entitynie wydaje się nieprawidłowy kod statusu HTTP dla twojego przypadku użycia, ponieważ ponieważ mówi wprowadzenie do RFC 4918:

Chociaż kody stanu dostarczone przez HTTP / 1.1 są wystarczające do opisania większości warunków błędów napotykanych przez metody WebDAV, istnieją pewne błędy, które nie mieszczą się w odpowiednich kategoriach. Ta specyfikacja określa dodatkowe kody statusu opracowane dla metod WebDAV (sekcja 11)

I opis422 mówi:

Kod statusu 422 (Unprocessable Entity) oznacza, że ​​serwer rozumie typ treści encji żądania (stąd kod statusu 415 (Unsupported Media Type) jest nieodpowiedni), a składnia encji żądania jest poprawna (a więc 400 (Bad Request ) kod stanu jest nieodpowiedni), ale nie mógł przetworzyć zawartych instrukcji.

(Zwróć uwagę na odniesienie do składni; podejrzewam, że 7231 częściowo przestarza również 4918)

To brzmi dokładnie tak , jak twoja sytuacja, ale na wypadek wątpliwości, mówi dalej:

Na przykład ten warunek błędu może wystąpić, jeśli treść żądania XML zawiera dobrze sformułowane (tj. Poprawne składniowo), ale semantycznie błędne instrukcje XML.

(Zamień „XML” na „JSON” i myślę, że możemy się zgodzić, że taka jest Twoja sytuacja)

Teraz niektórzy sprzeciwiają się temu, że RFC 4918 dotyczy „Rozszerzeń HTTP dla Web DistributedV Authoring and Versioning (WebDAV)” i że (prawdopodobnie) nie robisz nic związanego z WebDAV, więc nie powinieneś z tego korzystać.

Biorąc pod uwagę wybór między użyciem kodu błędu w oryginalnym standardzie, który wyraźnie nie obejmuje sytuacji, a jednym z rozszerzenia dokładnie opisującego sytuację, wybrałbym ten drugi.

Ponadto sekcja 21.4 RFC 4918 odnosi się do rejestru kodów statusu protokołu HTTP (IANA Hypertext Transfer Protocol) , w którym można znaleźć 422.

Proponuję, aby całkowicie uzasadnione było, aby klient lub serwer HTTP używał dowolnego kodu statusu z tego rejestru, o ile robi to poprawnie.


Ale od HTTP / 1.1 RFC 7231 ma przyczepność, więc po prostu użyj 400 Bad Request!

Kristian Glass
źródło
5
Twoja odpowiedź (422) ma dla mnie sens. Tego właśnie używa Rails ( respond_with ), gdy nie można przetworzyć zasobu z powodu błędów sprawdzania poprawności.
Tyler Rick
11
Zwróć uwagę na użycie 422 w specyfikacji innej niż WebDAV: tools.ietf.org/html/rfc5789#section-2.2
Andrey
4
Podobnie jak aktualizacja, RFC 7231 ma inny opis dla kodu odpowiedzi 400, który zmienia semantykę.
Lee Saferite,
5
Przepraszam - zaktualizowałem tę odpowiedź, aby odzwierciedlić zmianę w RFC i straciłem trochę jasności; Spróbuję refaktoryzować. Korzystanie z 422 jest prawie na pewno bezpieczne , ale w dzisiejszych czasach powinieneś używać 400.
Kristian Glass
2
Nadal uważam, że specyfikacja może być o wiele jaśniejsza. Przykłady podane w są wyraźnymi przypadkami, gdy klient robi coś złego. Sytuacja PO również należy do tej kategorii. Są jednak przypadki takie jak „Rozumiem, o co pytasz, ale odmawiam tego, ponieważ istnieją pewne reguły biznesowe przeciwko temu” nie jest tak jednoznaczne. To nie jest dokładnie wina klienta, więc 403 może faktycznie obowiązywać, zgodnie z tą samą specyfikacją: „Jednak żądanie może być zabronione z powodów niezwiązanych z poświadczeniami”. Wolałbym jednak mieć osobne kody dla rzeczy związanych z pozwoleniami niż „nie da się tego zrobić”.
Thorarin
37

400 Nieprawidłowe żądanie jest poprawnym kodem stanu HTTP dla twojego przypadku użycia. Kod jest zdefiniowany przez HTTP / 0.9-1.1 RFC.

Serwer nie mógł zrozumieć żądania z powodu nieprawidłowej składni. Klient NIE POWINIEN powtarzać żądania bez modyfikacji.

http://tools.ietf.org/html/rfc2616#section-10.4.1

422 Obiekt nieprzetworzony jest zdefiniowany w RFC 4918 - WebDav. Zauważ, że istnieje niewielka różnica w porównaniu do 400, patrz cytowany tekst poniżej.

Ten błąd może wystąpić, jeśli treść żądania XML zawiera dobrze sformułowane (tj. Poprawne składniowo), ale semantycznie błędne instrukcje XML.

Aby zachować jednolity interfejs, powinieneś używać 422 tylko w przypadku odpowiedzi XML, a także obsługiwać wszystkie kody statusu zdefiniowane przez rozszerzenie Webdav, a nie tylko 422.

http://tools.ietf.org/html/rfc4918#page-78

Zobacz także post Mark Nottingham na temat kodów statusu:

błędem jest „głębokie” mapowanie każdej części aplikacji na kody stanu HTTP; w większości przypadków poziom szczegółowości, do którego chcesz dążyć, jest znacznie grubszy. W razie wątpliwości można użyć ogólnych kodów stanu 200 OK, 400 Bad Request i 500 Internal Service Error, gdy nie ma lepszego dopasowania .

Jak myśleć o kodach stanu HTTP

filip26
źródło
4
Kod 422 jest częścią rejestru IANA iana.org/assignments/http-status-codes/http-status-codes.xhtml, więc żadne IMHO nie ma sensu. W każdym razie Facebook REST API Facebooka i Twittera wymyślają na nowo własne kody i nie używają standardów RFC / IANA. Więc możesz to zrobić.
gavenkoa
15
Sekcja 11 wyraźnie stwierdza, że ​​są dodawane do całej specyfikacji, a nie tylko do specyfikacji WebDav:The following status codes are added to those defined in HTTP/1.1 [RFC2616].
Steve Tauber
8
To, że kod jest opisany jako część specyfikacji WebDAV, nie oznacza, że ​​jest on specyficzny dla WebDAV! Kody stanu powinny być ogólne.
traktuj swoje mody dobrze
33

Aby odzwierciedlić status z 2015 r .:

Behawioralnie zarówno kody odpowiedzi 400, jak i 422 będą traktowane tak samo przez klientów i pośredników, więc w rzeczywistości nie robi to konkretnego różnicy, której używasz.

Spodziewałbym się jednak, że 400 będzie obecnie używanych w szerszym zakresie, a ponadto wyjaśnienia dostarczone przez specyfikację HTTPbis sprawiają, że jest bardziej odpowiedni z dwóch kodów statusu:

  • Specyfikacja HTTPbis wyjaśnia, że ​​400 nie ma na celu wyłącznie błędów składniowych. Używa się teraz szerszej frazy „wskazuje, że serwer nie może przetworzyć żądania z powodu czegoś, co jest postrzegane jako błąd klienta”.
  • 422 Jest konkretnie rozszerzeniem WebDAV i nie ma odniesienia w RFC 2616 ani w nowszej specyfikacji HTTPbis .

W kontekście, HTTPbis jest wersją specyfikacji HTTP / 1.1, która próbuje wyjaśnić obszary, które są niejasne lub niespójne. Po osiągnięciu statusu zatwierdzenia zastąpi RFC2616.

Tom Christie
źródło
4
Czy zatem 403 Forbidden może być również używany w tym kontekście? Cytat: Kod stanu 403 (Zabroniony) wskazuje, że serwer zrozumiał żądanie, ale odmawia autoryzacji ... Jeśli w żądaniu podano dane uwierzytelniające, serwer uważa je za niewystarczające, aby udzielić dostępu .... Jednak żądanie może być zabronione z powodów niezwiązanych z poświadczeniami. Wygląda więc na to, że 403 można użyć do odrzucenia żądań poza uwierzytelnieniem.
garbagecollector
1
@garbagecollector zauważa, że ​​„odrzucono z powodów niezwiązanych z poświadczeniami ”! = „odrzucono z powodów niezwiązanych z uwierzytelnieniem ”. Istnieje wiele sposobów uwierzytelnienia kogoś bez użycia poświadczeń.
Knetic
@garbagecollector nie, dane uwierzytelniające oznaczają uwierzytelnienie („kim jesteś”), które w przypadku niepowodzenia wynosiłoby 401. Autoryzacja („co można zrobić”) wynosiłaby 403 w przypadku awarii. Pełne wyjaśnienie tutaj: stackoverflow.com/a/6937030/137948 Ani nie dotyczy sytuacji „brakujących pól” PO, ponieważ błąd byłby taki sam, niezależnie od tego, który użytkownik próbował. Zgadzam się, że 400 jest właściwą odpowiedzią.
Will Sheppard,
27

Studium przypadku: GitHub API

https://developer.github.com/v3/#client-errors

Może kopiowanie ze znanych interfejsów API to mądry pomysł:

Istnieją trzy możliwe typy błędów klienta w wywołaniach API odbierających treści żądań:

Wysłanie niepoprawnego JSON spowoduje odpowiedź na 400 Błędnych żądań.

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

Wysłanie niewłaściwego typu wartości JSON spowoduje odpowiedź na 400 niepoprawnych żądań.

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

Wysłanie nieprawidłowych pól spowoduje odpowiedź 422 Nieprzetworzonego Podmiotu.

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}
Ciro Santilli
źródło
Myślę, że to poprawna i zrozumiała odpowiedź.
LEMUEL ADANE
1
Nie mogę głosować więcej. Żałuję, że więcej pozytywnych odpowiedzi nie odnosiłoby się do tego. Specyfikacje (RFC, IANA) zasadniczo nie dostarczyły jasnych definicji i rozróżnienia między nimi. Więc odpowiedź sprowadza się do najlepszych praktyk, a GitHub daje nam jedną.
Alex Klaus
15

Nie ma poprawnej odpowiedzi, ponieważ zależy to od definicji „składni” dla twojego żądania. Najważniejsze jest to, że:

  1. Konsekwentnie używaj kodów odpowiedzi
  2. W treści odpowiedzi umieść jak najwięcej dodatkowych informacji, aby pomóc programistom korzystającym z interfejsu API dowiedzieć się, co się dzieje. =

Zanim wszyscy podskoczą za mną, mówiąc, że nie ma tutaj dobrej lub złej odpowiedzi, pozwólcie, że wyjaśnię trochę, jak doszedłem do wniosku.

W tym konkretnym przykładzie pytanie OP dotyczy żądania JSON, które zawiera inny klucz niż oczekiwano. Teraz otrzymana nazwa klucza jest bardzo podobna, z punktu widzenia języka naturalnego, do oczekiwanego klucza, ale jest ściśle inna i dlatego (zwykle) nie jest rozpoznawana przez maszynę jako równoważna.

Jak powiedziałem powyżej, decydującym czynnikiem jest składnia . Jeśli żądanie zostało wysłane z typem treści application/json, to tak, żądanie jest poprawne składniowo, ponieważ jest poprawną składnią JSON, ale nie semantycznie poprawne , ponieważ nie pasuje do oczekiwanych. (zakładając ścisłą definicję tego, co powoduje, że dane zapytanie jest semantycznie ważne, czy nie).

Jeśli natomiast żądanie zostało wysłane z bardziej szczegółowym niestandardowym typem treści, takim jak application/vnd.mycorp.mydatatype+json ten, być może dokładnie określa, jakich pól należy się spodziewać, to powiedziałbym, że żądanie może być łatwo niepoprawne pod względem składniowym, stąd odpowiedź 400.

W omawianym przypadku, ponieważ klucz był nieprawidłowy, a nie wartość , wystąpił błąd składniowy, jeśli istniała specyfikacja prawidłowych kluczy. Jeśli nie podano specyfikacji poprawnych kluczy lub błąd miał wartość , byłby to błąd semantyczny .

cdeszaq
źródło
Bardzo niedoceniana odpowiedź - dziękuję za dobrze sformułowane wyjaśnienie.
puiu
Dokładnie moje przemyślenia na ten temat! Pochodzę z tła XML SOAP i koncepcja schematu właśnie dostała się do mojej krwi, a dokumenty JSON raczej nie ogłaszają swojego schematu. Dla mnie to, czy serwer „rozumie” żądanie, czy nie. Jeśli serwer nie wie, co to jest „sales_tax”, to jest to po prostu 400: „Nie mam pojęcia, co mi wysłałeś, ale zdecydowanie nie to, czego chcę”.
Aleksander Stelmaczonek
4

422 Wyjaśnienie podmiotu nieprzetworzonego Zaktualizowano: 6 marca 2017 r

Co to jest 422 nieprzetworzona jednostka?

Kod stanu 422 występuje, gdy żądanie jest poprawnie sformułowane, jednak z powodu błędów semantycznych nie można go przetworzyć. Ten status HTTP został wprowadzony w RFC 4918 i jest bardziej ukierunkowany na rozszerzenia HTTP dla Web Distributed Authoring and Versioning (WebDAV).

Istnieją pewne kontrowersje dotyczące tego, czy programiści powinni zwracać klientom błąd 400 vs 422 (więcej na temat różnic między obydwoma statusami poniżej). Jednak w większości przypadków uzgodniono, że status 422 powinien zostać zwrócony tylko wtedy, gdy obsługuje się funkcje WebDAV.

Definicję kodu statusu 422 słowo w słowo wziętą z sekcji 11.2 w RFC 4918 można przeczytać poniżej.

Kod statusu 422 (Unprocessable Entity) oznacza, że ​​serwer rozumie typ treści encji żądania (stąd kod statusu 415 (Unsupported Media Type) jest nieodpowiedni), a składnia encji żądania jest poprawna (a więc 400 (Bad Request ) kod stanu jest nieodpowiedni), ale nie mógł przetworzyć zawartych instrukcji.

Definicja dalej mówi:

Na przykład ten warunek błędu może wystąpić, jeśli treść żądania XML zawiera dobrze sformułowane (tj. Poprawne składniowo), ale semantycznie błędne instrukcje XML.

Kody statusu 400 vs 422

Błędy niepoprawnego żądania korzystają z kodu statusu 400 i powinny zostać zwrócone do klienta, jeśli składnia żądania jest źle sformułowana, zawiera niepoprawną ramkę komunikatu żądania lub ma oszukańczy routing żądania. Ten kod statusu może wydawać się bardzo podobny do statusu encji nieprzetworzonej 422, jednak jedną niewielką informacją, która je odróżnia, jest fakt, że składnia encji żądania dla błędu 422 jest poprawna, podczas gdy składnia żądania generującego 400 błąd jest niepoprawny.

Wykorzystanie statusu 422 powinno być zastrzeżone tylko dla bardzo szczególnych przypadków użycia. W większości innych przypadków, w których wystąpił błąd klienta z powodu nieprawidłowej składni, należy użyć statusu 400 Złych żądań.

https://www.keycdn.com/support/422-unprocessable-entity/

Clojurevangelist
źródło
1

Twoja sprawa: HTTP 400 jest właściwym kodem stanu dla Twojej sprawy z punktu widzenia REST, ponieważ sales_taxzamiast tego jest niepoprawny pod względem składniowym tax, mimo że jest to prawidłowy JSON. Jest to zwykle wymuszane przez większość frameworków po stronie serwera podczas mapowania JSON na obiekty. Istnieją jednak niektóre implementacje REST, które ignorują nowe keyw obiekcie JSON. W takim przypadku niestandardowa content-typespecyfikacja, która akceptuje tylko prawidłowe pola, może zostać wymuszona po stronie serwera.

Idealny scenariusz dla 422:

W idealnym świecie 422 jest preferowane i ogólnie akceptowalne do wysłania jako odpowiedź, jeśli serwer rozumie typ zawartości encji żądania, a składnia encji żądania jest poprawna, ale nie była w stanie przetworzyć danych, ponieważ jest semantycznie błędna.

Sytuacje 400 powyżej 422:

Pamiętaj, że kod odpowiedzi 422 jest rozszerzonym kodem statusu HTTP (WebDAV). Nadal istnieją niektóre klienty HTTP / biblioteki frontonu, które nie są przygotowane do obsługi 422. Dla nich jest to tak proste, jak „HTTP 422 jest zły, ponieważ to nie HTTP” . Z punktu widzenia usług 400 nie jest dość specyficzne.

W architekturze korporacyjnej usługi są wdrażane głównie na warstwach usług, takich jak SOA, IDM itp. Zazwyczaj obsługują wielu klientów, od bardzo starego klienta natywnego do najnowszych klientów HTTP. Jeśli jeden z klientów nie obsługuje protokołu HTTP 422, dostępne opcje to poproszenie klienta o aktualizację lub zmianę kodu odpowiedzi na HTTP 400 dla wszystkich. Z mojego doświadczenia wynika, że ​​obecnie jest to bardzo rzadkie, ale wciąż jest możliwe. Dlatego przed podjęciem decyzji o kodach odpowiedzi HTTP zawsze należy dokładnie przestudiować architekturę.

Aby poradzić sobie z taką sytuacją, warstwy usług zwykle używają versioninglub konfigurują configurationflagę dla klientów o ścisłej zgodności HTTP, aby wysłać 400, a 422 resztę. W ten sposób zapewniają one kompatybilność wsteczną dla istniejących klientów, ale jednocześnie zapewniają nowym klientom możliwość korzystania z protokołu HTTP 422.


Najnowsza aktualizacja RFC7321 mówi:

The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

Potwierdza to, że serwery mogą wysłać HTTP 400 w przypadku nieprawidłowego żądania. 400 nie odnosi się już tylko do błędu składniowego , jednak 422 nadal jest prawdziwą odpowiedzią, pod warunkiem, że klienci będą w stanie to obsłużyć.

YuVi
źródło
1

Po pierwsze, jest to bardzo dobre pytanie.

400 Błędne żądanie - gdy w żądaniu brakuje krytycznej informacji

np. nagłówek autoryzacji lub typ treści. Który jest absolutnie wymagany przez serwer do zrozumienia żądania. Może się to różnić w zależności od serwera.

422 Nieprzetworzona jednostka - gdy nie można przeanalizować treści żądania.

Jest to mniej poważne niż 400. Żądanie dotarło do serwera. Serwer potwierdził, że żądanie ma prawidłową podstawową strukturę. Ale informacji w treści żądania nie można przeanalizować ani zrozumieć.

na przykład Content-Type: application/xml gdy treść żądania to JSON.

Oto artykuł zawierający listę kodów stanu i jego zastosowania w interfejsach API REST. https://metamug.com/article/status-codes-for-rest-api.php


źródło
5
422 oznacza, że ​​składnia jest poprawna, ale treść nie jest. Wysłanie JSON w oczekiwanym formacie XML oznacza, że ​​składnia jest niepoprawna, więc w tym przypadku poprawną odpowiedzią jest 400.
Dirk
1
Dokładnie tak, jak powiedział Dirk, 422 oznacza poprawne składniowo żądanie (można je przeanalizować i zrozumieć), ale semantycznie nieprawidłowe
Jacek Obarymski,
400: gdy nie można przetworzyć żądania z powodu niepoprawnej składni (np. Błąd parsowania); 422: gdy nie można przetworzyć żądania z powodu nieprawidłowych danych (np. Błąd sprawdzania poprawności).
Kitanotori,
Twój przykład dla 422 jest nieprawidłowy, ponieważ wysyłając json z typem aplikacji / xml,
treść
-15

Powinieneś faktycznie zwrócić „200 OK”, a w treści odpowiedzi zamieścić komunikat o tym, co się stało z opublikowanymi danymi. Następnie Twoja aplikacja musi zrozumieć komunikat.

Chodzi o to, że kody stanu HTTP są dokładnie takie - kody stanu HTTP. I mają one mieć znaczenie tylko w warstwie transportowej, a nie w warstwie aplikacyjnej. Warstwa aplikacji nigdy nie powinna nawet wiedzieć, że używany jest HTTP. Jeśli zmieniłeś warstwę transportową z HTTP na Homing Pigeons, nie powinno to w żaden sposób wpływać na warstwę aplikacji.

Dam ci nie-wirtualny przykład. Powiedzmy, że zakochałeś się w dziewczynie, która kocha cię z powrotem, ale jej rodzina przenosi się do zupełnie innego kraju. Daje ci swój nowy adres ślimaka. Oczywiście decydujesz się wysłać jej list miłosny. Więc piszesz list, wkładasz go do koperty, zapisujesz jej adres na kopercie, kładziesz na niej znaczek i wysyłasz. Rozważmy teraz te scenariusze

  1. Zapomniałeś napisać nazwę ulicy. Otrzymasz z powrotem nieotwarty list z wypisaną na nim wiadomością, że adres jest źle sformułowany. Zepsułeś żądanie i poczta odbierająca nie jest w stanie go obsłużyć. Odpowiada to otrzymaniu „400 złych wniosków”.
  2. Więc popraw adres i ponownie wyślij list. Ale z powodu jakiegoś pecha całkowicie przeliterowałeś nazwę ulicy. Otrzymasz list z powrotem z komunikatem, że adres nie istnieje. Odpowiada to otrzymaniu komunikatu „404 Not Found”.
  3. Ponownie naprawisz adres i tym razem uda ci się poprawnie wpisać adres. Twoja dziewczyna otrzymuje list i odpisuje. Jest to odpowiednik otrzymania „200 OK”. Nie oznacza to jednak, że spodoba ci się to, co napisała w swoim liście. To po prostu oznacza, że ​​otrzymała twoją wiadomość i ma dla ciebie odpowiedź. Dopóki nie otworzysz koperty i nie przeczytasz jej listu, nie możesz wiedzieć, czy bardzo tęskni za tobą, czy też chce z tobą zerwać.

W skrócie: Zwrócenie „200 OK” nie oznacza, że ​​aplikacja serwera ma dla Ciebie dobre wieści. Oznacza to tylko, że ma jakieś wiadomości.

PS: Kod statusu 422 ma znaczenie tylko w kontekście WebDAV. Jeśli nie pracujesz z WebDAV, 422 ma dokładnie takie samo standardowe znaczenie, jak każdy inny niestandardowy kod = który nie jest żaden.

Iść wolno
źródło