Jaki kod HTTP powinien zostać zwrócony przez usługę interfejsu API REST w przypadku niepowodzenia sprawdzania poprawności?

394

Obecnie zwracam 401 nieautoryzowanych za każdym razem, gdy napotykam błąd sprawdzania poprawności w mojej aplikacji REST API opartej na Django / Piston . Po przejrzeniu rejestru kodów stanu HTTP nie jestem przekonany, że jest to odpowiedni kod do niepowodzenia sprawdzania poprawności, co wszyscy polecamy?

  • 400 złych wniosków
  • 401 Nieautoryzowane
  • 403 Zabronione
  • 405 Metoda niedozwolona
  • 406 Niedopuszczalne
  • 412 Warunek wstępny nie powiódł się
  • 417 Oczekiwanie nie powiodło się
  • 422 Podmiot nieprzetworzony
  • 424 Nieudana zależność

Aktualizacja : „Błąd sprawdzania poprawności” powyżej oznacza błąd sprawdzania poprawności danych na poziomie aplikacji, tj. Niepoprawnie określony czas, fałszywy adres e-mail itp.

michaeljoseph
źródło
2
Sprawdź tę odpowiedź: stackoverflow.com/a/2657624/221612
Kenny Meyer
3
Fwiw, link Kenny'ego sugeruje kod 422, tak jak teraz odpowiedź Jima poniżej . #TheMoreYouKnow #SavingYouAClick
ruffin
Myślę, że 401 jest bardziej jasne.
insign

Odpowiedzi:

298

Jeśli „błąd sprawdzania poprawności” oznacza, że ​​w żądaniu występuje błąd klienta, użyj HTTP 400 (niepoprawne żądanie). Na przykład, jeśli identyfikator URI ma mieć datę ISO-8601 i okaże się, że jest w niewłaściwym formacie lub odnosi się do 31 lutego, wówczas zwróci HTTP 400. Podobnie, jeśli spodziewasz się poprawnie sformatowanego XML w treści encji i nie można go przeanalizować.

(1/2016): W ciągu ostatnich pięciu lat bardziej szczegółowy protokół HTTP 422 (jednostka nieprzetworzona) WebDAV stał się bardzo rozsądną alternatywą dla HTTP 400. Zobacz na przykład jego użycie w JSON API . Należy jednak pamiętać, że HTTP 422 nie przeszedł na HTTP 1.1, RFC-7231 .

RESTful Web Services Richardsona i Ruby zawiera bardzo pomocny dodatek na temat tego, kiedy używać różnych kodów odpowiedzi HTTP. Mówią:

400 („Złe żądanie”)
Znaczenie: Wysoka.
Jest to ogólny stan błędu po stronie klienta, używany, gdy inny kod błędu 4xx nie jest odpowiedni. Jest powszechnie stosowany, gdy klient przesyła reprezentację wraz z żądaniem PUT lub POST, a reprezentacja ma odpowiedni format, ale nie ma to żadnego sensu. (str. 381)

i:

401 („Nieautoryzowany”)
Znaczenie: Wysoka.
Klient próbował działać na chronionym zasobie bez podania odpowiednich poświadczeń uwierzytelnienia. Być może podał on nieprawidłowe dane uwierzytelniające lub nie przedstawił ich wcale. Poświadczeniami może być nazwa użytkownika i hasło, klucz API lub token uwierzytelniający - niezależnie od tego, czego oczekuje dana usługa. Klient często wysyła żądanie identyfikatora URI i akceptuje kod 401, aby wiedział, jakie poświadczenia wysłać i w jakim formacie. [...]

Jim Ferrans
źródło
3
Ale prawdopodobnie jeśli format URI jest nieprawidłowy, 404 może być bardziej odpowiednie.
manu
11
Jak stwierdził @ReWrite, myślę również, że 422 jest lepszy w przypadku błędów sprawdzania poprawności.
panteo
11
Powiedziałbym, że to źle. 400 Niepoprawne żądanie jest używane, gdy w żądaniu występuje coś składniowego. Powiedziałbym, że ReWrite ma rację polecając 422, która dotyczy treści żądania.
Stijn de Witt
3
@Kenji tak, 401 („Nieautoryzowany”): „Być może podał nieprawidłowe dane uwierzytelniające ...” oznacza niewłaściwego użytkownika i / lub hasło.
razzintown
4
Błędy @JimFerrans 400 dotyczą niepoprawnej składni. Błędy 401 dotyczą w szczególności, gdy próbuję uzyskać dostęp do strony, do której muszę się zalogować, aby uzyskać do nich dostęp, i wcale się nie loguję. Błędy 422 dotyczą poprawnej składni, ale serwer odmawia usługi. Niepoprawna nazwa użytkownika / hasło to poprawna składnia (nie błąd 400) i nie próbuję uzyskać dostępu do strony, dla której muszę się zalogować, ponieważ uzyskuję dostęp do samej strony logowania (nie błąd 401). Błąd 401 powinien być używany do czegoś takiego jak strona ustawień, do której tylko użytkownik może uzyskać dostęp
Zachary Weixelbaum
98

Z RFC 4918 (i również udokumentowane na stronie http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ):

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

Przepisać
źródło
6
Polecam 422 - Nieprzetworzona jednostka dla błędów sprawdzania poprawności powyżej 400 - Złe żądanie
java_geek
19

Oto on:

rfc2616 # section-10.4.1 - 400 Złe żądanie

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

rfc7231 # sekcja-6.5.1 - 6.5.1. 400 złych wniosków

Kod statusu 400 (Błędne żądanie) wskazuje, że serwer nie może lub nie będzie przetwarzał żą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 mylące kierowanie żądania) .

Odnosi się do zniekształconych (źle sformatowanych) przypadków!

rfc4918 - 11,2. 422 Podmiot nieprzetworzony

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

Wniosek

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

422 pasuje do błędu sprawdzania poprawności najlepszego obiektu (dokładnie moja zalecenie :)
Co do błędu semantycznego - Pomyśl o czymś takim jak sprawdzanie poprawności „Ta nazwa użytkownika już istnieje”.

400 jest niepoprawnie używany do sprawdzania poprawności obiektu

honzajde
źródło
9

Powiedziałbym, że technicznie nie może to być błąd HTTP, ponieważ zasób został (prawdopodobnie) poprawnie określony, użytkownik został uwierzytelniony i nie wystąpił błąd operacyjny (jednak nawet specyfikacja zawiera niektóre zastrzeżone kody, takie jak 402 Wymagana płatność, które nie są t ściśle związane z HTTP, chociaż może być wskazane, aby mieć to na poziomie protokołu, aby każde urządzenie mogło rozpoznać warunek).

Jeśli tak jest w rzeczywistości, dodam pole stanu do odpowiedzi z błędami aplikacji, takimi jak

<status><code>4</code> <message> Niepoprawny zakres dat </message> </status>

jspcal
źródło
1

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

Osobiście prawdopodobnie skorzystałbym 400 Bad Request, ale to tylko moja osobista opinia bez jakiegokolwiek faktycznego wsparcia.

andri
źródło
0

Co dokładnie rozumiesz przez „błąd sprawdzania poprawności”? Co zatwierdzasz? Czy masz na myśli coś takiego jak błąd składniowy (np. Źle sformułowany XML)?

Jeśli tak jest, powiedziałbym, że 400 złych żądań jest prawdopodobnie właściwą rzeczą, ale nie wiedząc, co to jest „sprawdzanie poprawności”, nie można powiedzieć.

Nicholas Knight
źródło
co jeśli staramy się zweryfikować niektóre zasady lub reguły biznesowe.
Metalhead