Prawidłowy kod statusu HTTP do złego wprowadzenia

Jaki jest optymalny kod odpowiedzi HTTP, jeśli nie zgłasza 200 (wszystko jest w porządku), ale błąd danych wejściowych?

Na przykład przesyłasz jakieś dane do serwera, a on odpowie, że Twoje dane są nieprawidłowe

używanie 500wygląda bardziej jak problem z serwerem
używanie 200z ostrzeżeniem / błędem tekst odpowiedzi jest zły (zezwala na buforowanie i wszystko nie jest w porządku)
używanie 204i zwracanie niczego, może jest dobre (ale dobrze obsługiwane?)
użycie 404jest nieprawidłowe, jeśli żądana ścieżka (skrypt) jest dostępna i we właściwym miejscu

Mieliśmy ten sam problem podczas tworzenia naszego API. Szukaliśmy kodu stanu HTTP odpowiadającego plikowi InvalidArgumentException. Po przeczytaniu poniższego artykułu źródłowego użyliśmy następujących 422 Unprocessable Entitystwierdzeń:

Kod statusu 422 (Unprocessable Entity) oznacza, że ​​serwer rozumie typ zawartości jednostki żądania (stąd kod statusu 415 (Unsupported Media Type) jest nieodpowiedni), a składnia jednostki żądania jest poprawna (a zatem 400 (Bad Request ) kod statusu 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 poprawnie sformułowane (tj. Poprawne składniowo), ale semantycznie błędne instrukcje XML.

źródło: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

Kody zaczynające się od 4 (4xx) są przeznaczone dla błędów klienta. Może 400 (złe żądanie) mogłoby być odpowiednie w tym przypadku? Definicja w http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html mówi:

„Żądanie nie mogło zostać zrozumiane przez serwer z powodu nieprawidłowej składni. Klient NIE POWINIEN powtarzać żądania bez modyfikacji”.

Oprócz specyfikacji RFC można to również zobaczyć w akcji. Sprawdź odpowiedzi na Twitterze.

https://developer.twitter.com/en/docs/ads/general/guides/response-codes

409 Conflict mogłoby być akceptowalnym rozwiązaniem.

Według: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Żądanie nie mogło zostać zrealizowane z powodu konfliktu z bieżącym stanem zasobu. Ten kod jest dozwolony tylko w sytuacjach, w których oczekuje się, że użytkownik będzie w stanie rozwiązać konflikt i ponownie przesłać żądanie. Treść odpowiedzi POWINNA zawierać wystarczającą ilość informacji, aby użytkownik mógł rozpoznać źródło konfliktu. Idealnie byłoby, gdyby jednostka odpowiedzi zawierała wystarczającą ilość informacji dla użytkownika lub agenta użytkownika, aby rozwiązać problem; jednak może to nie być możliwe i nie jest wymagane.

Dokument kontynuuje przykład:

Konflikty najprawdopodobniej wystąpią w odpowiedzi na żądanie PUT. Na przykład, jeśli używane były wersje, a jednostka PUT zawierała zmiany w zasobie, które są sprzeczne z tymi wprowadzonymi przez wcześniejsze żądanie (strony trzeciej), serwer może użyć odpowiedzi 409, aby wskazać, że nie może wykonać żądania . W takim przypadku jednostka odpowiedzi prawdopodobnie zawierałaby listę różnic między dwiema wersjami w formacie zdefiniowanym przez odpowiedź Content-Type.

W moim przypadku chciałbym umieścić ciąg, który musi być unikalny, w bazie danych za pośrednictwem API. Przed dodaniem go do bazy sprawdzam, czy nie ma go już w bazie.

Jeśli tak, wrócę "Error: The string is already in the database", 409.

Uważam, że właśnie tego chciał OP: kod błędu odpowiedni na wypadek, gdyby dane nie spełniały kryteriów serwera.

Zgodnie z poniższym scenariuszem

Powiedzmy, że ktoś wysyła żądanie do Twojego serwera z danymi, które są w odpowiednim formacie, ale po prostu nie są „dobrymi” danymi. Na przykład wyobraź sobie, że ktoś wysłał wartość typu String do punktu końcowego interfejsu API, który oczekiwał wartości typu String; ale wartość ciągu zawierała dane, które były na czarnej liście (np. uniemożliwiały ludziom używanie „hasła” jako hasła). wtedy kod statusu mógłby wynosić 400 lub 422?

Do tej pory zwracałbym „400 złych żądań”, co według w3.org oznacza:

Żądanie nie mogło zostać zrozumiane przez serwer z powodu nieprawidłowej składni. Klient NIE POWINIEN powtarzać żądania bez modyfikacji.

Ten opis nie do końca pasuje do okoliczności; ale jeśli przejdziesz przez listę podstawowych kodów stanu HTTP zdefiniowanych w protokole HTTP / 1.1, jest to prawdopodobnie najlepszy wybór.

Ostatnio jednak ktoś z mojego zespołu deweloperów zwrócił mi uwagę, że popularne interfejsy API zaczynają używać rozszerzeń HTTP, aby uzyskać bardziej szczegółowe informacje o raportowaniu błędów. W szczególności wiele interfejsów API, takich jak Twitter i Recurly, używa kodu stanu „422 Unprocessable Entity”, zgodnie z definicją w rozszerzeniu HTTP dla WebDAV. Kod stanu HTTP 422 mówi:

Kod statusu 422 (Unprocessable Entity) oznacza, że ​​serwer rozumie typ zawartości jednostki żądania (stąd kod statusu 415 (Unsupported Media Type) jest nieodpowiedni), a składnia jednostki żądania jest poprawna (a zatem 400 (Bad Request ) kod statusu 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 poprawnie sformułowane (tj. Poprawne składniowo), ale semantycznie błędne instrukcje XML.

Wracając do naszego przykładu hasła z góry, ten kod statusu 422 wydaje się znacznie bardziej odpowiedni. Serwer rozumie, co próbujesz zrobić; i rozumie dane, które przesyłasz; po prostu nie pozwoli na przetwarzanie tych danych.

404 - Nie znaleziono - można użyć dla Żądany identyfikator URI jest nieprawidłowy lub żądany zasób, taki jak użytkownik, nie istnieje.