Jaki jest odpowiedni kod statusu HTTP zwracany przez usługę REST API w przypadku niepowodzenia walidacji?

Question

Jaki jest odpowiedni kod statusu HTTP zwracany przez usługę REST API w przypadku niepowodzenia walidacji?

Zwracam obecnie 401 nieautoryzowanych za każdym razem, gdy napotkam błąd walidacji w moim Django/tłok oparta aplikacja REST API. Po obejrzeniu rejestru kodów statusu HTTP Nie jestem przekonany, czy jest to odpowiedni kod do niepowodzenia walidacji, co polecacie?

400 Bad Request
401 Nieautoryzowano
403 Forbidden
405 Metoda Niedozwolona
406 Nie Do Przyjęcia
412 Warunek Wstępny Nie Powiódł Się
417 Oczekiwanie Nie Powiodło Się
422]}
424 Nie Powiodło Się Zależność

Update:" awaria walidacji " powyżej oznacza awarię walidacji danych na poziomie aplikacji, tj. nieprawidłowo określony datetime, fałszywy adres e-mail itp.

416

rest validation http-status-codes

Author: George Stocker, 2009-12-24

Source

7 answers

Z RFC 4918 (a także udokumentowane na http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml):

Kod statusu 422 (Unprocessable Entity) oznacza serwer rozumie typ zawartości jednostki żądania (stąd 415 (nieobsługiwany typ nośnika) kod stanu jest nieodpowiedni), a składnia encji żądania jest poprawna (a więc 400 (Bad Request) kod stanu jest niewłaściwy) , ale nie był w stanie przetworzyć zawartego instrukcje. Na przykład ten warunek błędu może wystąpić, jeśli XML ciało żądania zawiera dobrze uformowane (tzn. poprawne składniowo), ale semantycznie błędne instrukcje XML.

101

Author: ReWrite,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-01-09 03:39:42

Duplikat w bazie danych powinien być 409 CONFLICT.

Zalecam użycie 422 UNPROCESSABLE ENTITY do błędów walidacji.

Podaję tu dłuższe Wyjaśnienie kodów 4xx: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

31

Author: Phil Parker,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-10-16 23:06:37

Oto jest:

Rfc2616#section-10.4.1-400 Bad Request

Żądanie nie może być zrozumiane przez serwer z powodu nieprawidłowego składnia . Klient nie powinien powtarzać żądania bez modyfikacji.

Rfc7231#sekcja-6.5.1 - 6.5.1. 400 Bad Request

Kod statusu 400 (Bad Request) wskazuje, że serwer nie może lub nie przetworzy żądania z powodu czegoś, co jest postrzegane być błąd klienta(np. nieprawidłowa składnia żądania, nieprawidłowe kadrowanie wiadomości żądania lub zwodnicze routing żądania).

Odnosi się do przypadków zniekształconych (nie dobrze ukształtowanych)!

Rfc4918 - 11.2. 422 Unprocessable Entity

Kod statusu 422 (Unprocessable Entity) oznacza Serwer
rozumie typ zawartości encji żądania (stąd kod stanu 415 (nieobsługiwany typ nośnika) jest niewłaściwy) oraz składnię encja żądania jest poprawna (zatem kod statusu 400 (Bad Request) jest niewłaściwy), ale nie była w stanie przetworzyć zawartych instrukcji. Na przykład ten warunek błędu może wystąpić, jeśli ciało żądania XML zawiera dobrze uformowane (tj. poprawne składniowo), ale semantycznie błędne instrukcje XML.

Wniosek

Zasada: [_] 00 obejmuje najbardziej ogólny przypadek i przypadki, które nie są objęte wyznaczonym kodem.

422 pasuje najlepszy błąd walidacji obiektu (dokładnie moje zalecenie:)
Jeśli chodzi o semantycznie błędne- pomyśl o czymś takim jak Walidacja "ta nazwa użytkownika już istnieje".

400 jest niepoprawnie używany do walidacji obiektów

19

Author: honzajde,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-08-26 21:16:54

Powiedziałbym technicznie, że nie może to być awaria HTTP, ponieważ zasób został (przypuszczalnie) poprawnie określony, użytkownik został uwierzytelniony i nie było żadnej awarii operacyjnej (jednak nawet Specyfikacja zawiera pewne zastrzeżone kody, takie jak 402 wymagane płatności, które nie są ściśle związane z HTTP albo, choć może być wskazane, aby mieć to na poziomie protokołu, tak, że każde urządzenie może rozpoznać warunek).

Jeśli tak jest, dodałbym pole status do odpowiedzi z błędami aplikacji, np.

4 zakres dat jest nieprawidłowy

9

Author: jspcal,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-06 04:39:12

Jest trochę więcej informacji na temat semantyki tych błędów w RFC 2616 , który dokumentuje HTTP 1.1.

Osobiście pewnie użyłbym 400 Bad Request, ale to tylko moja osobista opinia bez żadnego merytorycznego poparcia.

1

Author: andri,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-24 22:38:40

Co dokładnie masz na myśli przez "niepowodzenie walidacji"? Co potwierdzasz? Czy chodzi ci o coś w rodzaju błędu składni (np. nieprawidłowy XML)?

Jeśli tak jest, powiedziałbym, że 400 złych próśb jest prawdopodobnie właściwą rzeczą, ale nie wiedząc, co to jest "Walidacja", nie można powiedzieć.

0

Author: Nicholas Knight,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-24 22:38:43

score 314 · Accepted Answer

Jeśli "validation failure" oznacza, że w żądaniu wystąpił błąd klienta, użyj HTTP 400 (Bad Request). Na przykład, jeśli URI ma mieć datę ISO-8601 i okaże się, że jest w złym formacie lub odnosi się do 31 lutego, zwrócisz HTTP 400. Tak samo, jeśli oczekujesz dobrze uformowanego XML w ciele encji i nie będzie on analizowany.

(1/2016): w ciągu ostatnich pięciu lat WebDAV bardziej szczegółowy HTTP 422 (nieprzetworzony podmiot) stał się bardzo rozsądna alternatywa dla HTTP 400. Zobacz na przykład jego użycie w JSON API . Należy jednak pamiętać, że HTTP 422 ma nie został przekształcony w HTTP 1.1, RFC-7231 .

Richardson and Ruby ' s RESTful Web Services zawiera bardzo pomocny dodatek, kiedy używać różnych kodów odpowiedzi HTTP. Mówią:

400 ("Zła Prośba")
Znaczenie: Wysokie.
Jest to ogólny stan błędu po stronie klienta, używany, gdy żaden inny kod błędu 4xx nie jest odpowiednie. Jest powszechnie używany, gdy Klient przesyła reprezentację wraz z PUT lub POST request, a reprezentacja jest w odpowiednim formacie, ale nie czyni jakikolwiek sens. (str. 381)

I:

401 ("Nieautoryzowano")
Znaczenie: Wysokie.
Klient próbował działać na chronionym zasobie bez podania odpowiednich poświadczeń uwierzytelniania. Mógł podać błędne dane uwierzytelniające lub w ogóle nie. Listy uwierzytelniające mogą być nazwą użytkownika i hasłem, kluczem API lub uwierzytelnieniem token-niezależnie od tego, czego oczekuje dana usługa. Często klient robi Prośba o URI i zaakceptowanie 401 tylko po to, żeby wiedział jakie poświadczenia wysłać i w jakim formacie. [...]