Kod odpowiedzi REST dla nieprawidłowych danych

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.

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.

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.

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 .

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.