Odpowiedź 400 vs 422 na test POST danych

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.

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!

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

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.

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"
    }
  ]
}

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 .

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/

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ć.

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

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.