Kod odpowiedzi REST dla nieprawidłowych danych


272

Jaki kod odpowiedzi należy przekazać klientowi w przypadku następujących scenariuszy?

  1. Nieprawidłowe dane przekazane podczas rejestracji użytkownika, takie jak niewłaściwy format wiadomości e-mail
  2. Nazwa użytkownika / adres e-mail już istnieje

Wybrałem 403. Stwierdziłem również, że według mnie można go użyć.

Wikipedia:

412 Warunek wstępny nie powiódł się: Serwer nie spełnia jednego z warunków wstępnych postawionych przez żądającego

Zaproponuj kod, jeśli powinienem użyć innego niż 403.



Rozwiązuję również ten problem. Rozdział 7. Weryfikacja specyfikacji JAX-RS (2017) zawiera porady dotyczące kodów statusu, szczególnie w przypadku naruszeń ograniczeń. download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/…
burntsugar

Odpowiedzi:


298

400 jest najlepszym wyborem w obu przypadkach. Jeśli chcesz dokładniej wyjaśnić błąd, możesz zmienić frazę przyczyny lub dołączyć treść wyjaśniającą błąd.

412 - Niepowodzenie warunku wstępnego jest używane dla żądań warunkowych, gdy używana jest data ostatniej modyfikacji i znaczniki ETag.

403 - Zabronione jest używane, gdy serwer chce uniemożliwić dostęp do zasobu.

Jedynym możliwym wyborem jest 422 - jednostka nieprzetworzona.


10
chociaż jest często używany w tym kontekście, 403 nie ogranicza się do kontroli dostępu, ponieważ rfc2616-10.4.4 mówi: „Serwer zrozumiał żądanie, ale odmawia jego spełnienia. [...] jeśli serwer chce dokonać publicznie, dlaczego prośba nie została spełniona, POWINIEN opisać przyczynę odmowy w podmiocie ”. Przyczyną mogą być nieprawidłowe dane. Jednak 422 ma tutaj większe zastosowanie.
Yannick Loiseau,

7
Nie dajmy się wciągnąć w krytykę tekstową. Zobacz na przykład trac.tools.ietf.org/wg/httpbis/trac/ticket/294, który próbuje wyjaśnić, że 403 dotyczy i zawsze dotyczy autoryzacji.
fumanchu

2
@fumanchu Nice catch. Link do żądania zmiany, które ma tylko 7 godzin :-)
Darrel Miller

1
@fumanchu Oznacza to, że 403 powinien zostać zwrócony, jeśli użytkownik nie ma uprawnień dostępu do żądanego zasobu. Ale myślę, że 401 Nieautoryzowane jest bardziej odpowiednie do uzyskiwania dostępu do zasobu, na który użytkownik nie ma uprawnień.
Amit Patel

1
401 Nieautoryzowany poprosi przeglądarkę internetową o wyświetlenie użytkownikowi standardowej nazwy użytkownika / hasła HTTP. Jeśli nie używasz tego rodzaju uwierzytelniania dla swojej usługi lub jeśli użytkownik ma już uwierzytelnianie HTTP, 401 nie jest odpowiednie.
Greg Ball,

92

Polecam 422. Nie jest to część głównej specyfikacji HTTP, ale jest zdefiniowana przez standard publiczny (WebDAV) i powinna być traktowana przez przeglądarki tak samo, jak każdy inny kod statusu 4xx.

Od RFC 4918 :

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.


20
Zauważ, że cytowany tekst stwierdza, że ​​422 ma zastosowanie, gdy encja żądania jest poprawnie sformatowana składniowo, ale semantycznie błędna. Jeśli encja żądania jest zniekształcona, odpowiednia jest odpowiedź 400.
Matty K,

87

Jeśli żądanie nie może zostać poprawnie przeanalizowane (w tym jednostka / treść żądania), odpowiednią odpowiedzią jest 400 Błędne żądanie [ 1 ].

RFC 4918 stwierdza, że 422 „nieprzetworzona jednostka” ma zastosowanie, gdy jednostka żądania jest poprawnie sformatowana, ale semantycznie błędna. Więc jeśli encja żądania jest zniekształcona (jak zły format wiadomości e-mail), użyj 400; ale jeśli to nie ma sensu (jak @example.com) użyj 422.

Jeśli problem polega na tym, że jak podano w pytaniu, nazwa użytkownika / adres e-mail już istnieje, możesz użyć 409 Konflikt [ 2 ] z opisem konfliktu i wskazówką, jak go naprawić (w tym przypadku „wybierz inna nazwa użytkownika / adres e-mail ”). Jednak w opisie, jak napisano, 403 Forbidden [ 3 ] może być również użyte w tym przypadku, niezależnie od argumentów dotyczących autoryzacji HTTP.

412 Warunek wstępny nie powiódł się [ 4 ], gdy nagłówek żądania warunku wstępnego (np. If-Match), Który został dostarczony przez klienta, ma wartość false. Oznacza to, że klient zażądał czegoś i dostarczył warunki wstępne, doskonale wiedząc, że warunki te mogą zawieść. 412 nigdy nie powinno być wyskakiwane na kliencie nieoczekiwanie i nie powinno być powiązane z jednostką żądania per se .


1
Powinienem zwrócić uwagę na zaktualizowane RFC HTTP / 1.1: 400 Błędne żądanie, 409 Konflikt, 403 Zakazane itp. Na żywo w tools.ietf.org/html/rfc7231 ; 412 Warunek wstępny
Matty K

41

Zabawne jest wracanie do 418 I'm a teapotżądań, które są w oczywisty sposób spreparowane lub złośliwe i „nie mogą się zdarzyć”, takich jak nieudane sprawdzenie CSRF lub brak właściwości żądań.

2.3.2 418 Jestem czajnikiem

Każda próba parzenia kawy za pomocą czajnika powinna skutkować kodem błędu „418 Jestem czajnikiem”. Wynikowa treść podmiotu MOŻE być niska i gruba.

Aby zachować rozsądność, ograniczam użycie śmiesznych kodów błędów do punktów końcowych RESTful, które nie są bezpośrednio narażone na działanie użytkownika.


11
Zaimplementuj go w taki sposób, aby interfejs API 418 I'm a teapot
zwracał

2
@vikarjramun zbudowałem atrapę REST i uczyniłem ją ostrożną offline. (wersja wstępna) teraz nasi uczniowie szukają sposobów na utworzenie prawidłowych żądań danych, ale to wszystko czajniczek. Jestem „szefem” - ale to też działa.
LenglBoy,

2
Ten RFC jest głupi. Możesz zaparzyć kawę w dzbanku do herbaty, o ile wlejesz ją przez sitko do filiżanki do filiżanki. Podobnie jak w przypadku luźnej herbaty liściastej. Możesz także zrobić herbatę w kawiarni bez żadnych problemów.
gburton

2
@gburton To jednak wymaga interwencji człowieka. W sieci zdecydowanie potrzebujesz urządzenia z kawą, aby przygotować kawę. Oczywiście, dzbanek do kawy i czajnika nie powinien odpowiadać 418.
Jasper
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.