Jakiego kodu odpowiedzi statusu HTTP należy użyć, jeśli w żądaniu brakuje wymaganego parametru?

Odpowiedzi:

387

Status 422 wydaje się najbardziej odpowiedni na podstawie specyfikacji .

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.

Twierdzą, że źle sformułowany plik XML jest przykładem złej składni (woła o 400). Zniekształcony ciąg zapytania wydaje się analogiczny do tego, więc 400 nie wydaje się odpowiednie dla poprawnie sformułowanego ciągu zapytania, w którym brakuje parametru.

AKTUALIZACJA @DavidV poprawnie wskazuje, że ta specyfikacja dotyczy WebDAV, a nie rdzenia HTTP. Ale niektóre popularne interfejsy API inne niż WebDAV i tak używają 422, z powodu braku lepszego kodu stanu ( zobacz to ).

kelwin
źródło
2
IMO użyłbym tego, gdy wartość w ciągu zapytania była niepoprawna, a nie wtedy, gdy była dodatkowa lub brakująca wartość. to znaczy. Oczekiwanie na e-mail i jego wartość to „123123”
Derek Litz
2
Często myślę o parametrach GET i POST jako metodzie podpisu ścieżki adresu URL, więc 404 ma dla mnie sens. W interfejsie API RESTful przeznaczonym do użytku publicznego rozsądne jest zwracanie brakujących / dodatkowych parametrów. W kontekście adresu URL parametry ciągu zapytania są zwykle ważne dla identyfikacji zasobu, a dodatkowe lub brakujące parametry reprezentują zasób, który nie istnieje, bez żadnych założeń. Oczywiście istnieją kompromisy z solidnością poprzez jawność, a opcjonalne parametry czynią zasób potencjalnie równie podatnym na cichy błąd. Potem jest użyteczność ...
Derek Litz
13
Podana specyfikacja dotyczy WebDAV i nie jest standardową specyfikacją HTTP.
David V
1
@Kelvin Dzięki za wskazanie tego posta na blogu. Na przykład warto zauważyć, że Twitter używa 422. Myślę, że odpowiedź może być lepsza, jeśli wyjaśnisz, że specyfikacją jest WebDAV w pierwszym wierszu. Kiedy po raz pierwszy przeczytałem twoją odpowiedź, myślałem, że masz na myśli standardową specyfikację HTTP, dopóki nie podążyłem za linkiem.
David V
3
Warto to przeczytać: bennadel.com/blog/... Nie użyłbym również 422 za brakujące parametry. Myślę, że 400jest bardziej odpowiedni.
Zelphir Kaltstahl
184

Nie jestem pewien, czy istnieje ustalony standard, ale użyłbym 400 złych żądań , które najnowsza specyfikacja HTTP (z 2014 r.) Dokumentuje w następujący sposób :

6.5.1 400 złych wniosków

Kod statusu 400 (Błędne żądanie) wskazuje, że serwer nie może lub nie przetworzy żą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 oszukańczy routing żądania).

Gert Grenander
źródło
65
400 Bad Requestma wskazywać problemy na poziomie protokołu, a nie błędy semantyczne. Jeśli mamy zamiar przejąć kody stanu HTTP, aby wskazać błędy na poziomie aplikacji (a nie na poziomie protokołu), dlaczego nie przejść do końca i po prostu użyć 412?
Matt Zukowski,
36
Implementacja Google OAuth 1.0 zgadza się z tą odpowiedzią. Podana jest odpowiedź 400, gdy brakuje parametrów POST lub są one nieobsługiwane: code.google.com/apis/accounts/docs/OAuth_ref.html
Tom
1
@ matt-zukowski: „412: Warunek podany w co najmniej jednym polu nagłówka żądania został oceniony jako fałszywy, gdy został przetestowany na serwerze.” z RFC2616 - Jeśli jest to test POST, parametry znajdują się w treści żądania, a nie w polach nagłówka żądania. Technicznie rzecz biorąc, metoda GET wysyła swoje parametry w nagłówkach żądań, ale wolałbym raczej zachować spójność?
toong 1'12
6
@MattZukowski 400 to kod statusu poziomu aplikacji. Jeśli spojrzysz na przeredagowanie w wersji roboczej RFC 7231, zobaczysz to. Niestety, sformułowania w najnowszej wersji nie są tak jasne, ponieważ autor najnowszych zmian wynalazł również 422.
Darrel Miller
9
@DarrelMiller ma rację ( bezpośredni link ): „Kod stanu 400 (Błędne żądanie) wskazuje, że serwer nie może przetworzyć żądania z powodu czegoś, co jest postrzegane jako błąd klienta (np. Źle sformułowana składnia żądania, niepoprawny komunikat żądania) kadrowanie lub oszukańczy routing żądań). ” W zależności od semantyki i oczekiwań dotyczących rozszerzalności (czy pewnego dnia możliwe będzie wydanie żądania bez parametru?), Wtedy tylko 400 i 404 wydają się odpowiednie w standardowym HTTP. W przeciwnym razie wymyśl nowy kod dla swojego interfejsu API, ale nie przeciążaj semantyki.
tne
31

WCF API w uchwyty .NET brakuje parametrów poprzez odesłanie HTTP 404„Endpoint Not Found” błąd, gdy za pomocą webHttpBinding .

404 Not FoundMoże mieć sens, jeśli wziąć pod uwagę swój serwis WWW nazwę metody wraz z jego podpisem parametrów. Oznacza to, że jeśli ujawnisz metodę usługi sieci Web LoginUser(string, string)i poprosisz LoginUser(string), tej drugiej nie można znaleźć.

Zasadniczo oznaczałoby to, że nie można znaleźć wywoływanej metody usługi sieci Web oraz podanego podpisu parametru.

10.4.5 404 Nie znaleziono

Serwer nie znalazł nic pasującego do URI żądania. Nie podano żadnych wskazówek, czy stan jest tymczasowy czy trwały.

400 Bad Request, Jak sugeruje Gert pozostaje ważny kod odpowiedzi, ale myślę, że jest zwykle używany do wskazania problemów z niższego poziomu. Można to łatwo zinterpretować jako zniekształcone żądanie HTTP, być może brakujące lub nieprawidłowe nagłówki HTTP lub podobne.

10.4.1 400 Zła prośba

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

Daniel Vassallo
źródło
To właśnie domyślnie robi CherryPy.
Derek Litz,
A co z obsługą żądania postu, w którym akceptujesz model i brakuje części modelu? W takim przypadku nie dostajesz 404. Zamiast tego dostajesz model, który nie jest ważny, jeśli się nie mylę i musisz zdecydować, co robić teraz.
Shane Courtrille,
1
Ta interpretacja wydaje się rozciągnięta i wyraża RPC zamiast pow REST. Identyfikator URI to identyfikator, który istnieje i został znaleziony. To, co jest wysyłane w treści, nie jest częścią identyfikatora zasobu. 422 jest bardziej odpowiednie.
Jonasz
404 to właściwa odpowiedź, po prostu edytuj kilka adresów URL w sieci, aby znaleźć konsensus!
jenson-button-event
8

Możesz wysłać 400 błędny kod żądania. Jest to jeden z bardziej ogólnych kodów statusu 4xx, więc możesz go użyć, aby oznaczać to, co zamierzasz: klient wysyła żądanie, w którym brakuje informacji / parametrów wymaganych przez aplikację w celu prawidłowego przetworzenia.

BoltClock
źródło
7

W jednym z naszych projektów API postanawiamy ustawić status 409 na niektóre żądania, gdy nie możemy wypełnić go w 100% z powodu braku parametru.

Kod statusu HTTP „Konflikt 409” był dla nas dobrą próbą, ponieważ jego definicja wymaga podania wystarczającej ilości informacji, aby użytkownik mógł rozpoznać źródło konfliktu.

Odniesienie: w3.org/Protocols/

Tak więc wśród innych odpowiedzi, takich jak 400 lub 404, wybraliśmy 409, aby wymusić potrzebę przejrzenia niektórych notatek w żądaniu, które pomogą ustalić nowe i właściwe żądanie.

W każdym razie nasz przypadek był szczególny, ponieważ musimy wysłać wigilię danych, jeśli żądanie nie było całkowicie poprawne, i musimy zmusić klienta do spojrzenia na wiadomość i zrozumienia, co było nie tak w żądaniu.

Ogólnie, jeśli mamy tylko brakujący parametr, wybieramy 400 i tablicę brakującego parametru. Ale kiedy musimy wysłać więcej informacji, na przykład konkretny komunikat sprawy i chcemy być bardziej pewni, że klient się tym zajmie, wysyłamy 409

gabrielem
źródło
2
To jest po prostu źle. 409 dotyczy problemów z współbieżnością, ponieważ @ MaximeGélinas wskazuje LUB sytuacje, w których zasób jest już obecny, a duplikaty nie są dozwolone.
gimlichael 12.01.19
Według specyfikacji „Kod stanu 409 (konflikt) wskazuje, że żądanie nie mogło zostać zrealizowane z powodu konfliktu z bieżącym stanem zasobu docelowego”. . Używanie go jako brakującego parametru jest po prostu błędne; to zupełnie inny rodzaj błędu.
Mark Amery
5

Zwykle wybieram 422 (encja nieprzetworzona), jeśli coś w wymaganych parametrach nie odpowiada wymaganemu punktowi końcowemu API (jak zbyt krótkie hasło), ale dla brakującego parametru wybrałbym 406 (niedopuszczalne).

Elad Meidar
źródło
8
Cóż, 406 Niedopuszczalne jest używane z nagłówkiem Akceptuj (jeśli serwer nie może wysłać odpowiedzi, klient zrozumie). „Zasób zidentyfikowany w żądaniu może generować tylko jednostki odpowiedzi, których właściwości treści są niedopuszczalne zgodnie z nagłówkami akceptacji wysłanymi w żądaniu.” .
Utknąłem
Używanie do tego 406 jest nieprawidłowe. Kod 406 nie oznacza, że żądanie było nie do przyjęcia; oznacza to, że nie możesz spełnić żądania, ponieważ odpowiedzi, które możesz podać, są odpowiedziami, które klient uznałby za niedopuszczalne, na podstawie nagłówków Akceptuj wysłanych w żądaniu. (Na przykład, dołączone żądanie Accept-Language: de, wskazujące, że akceptuje tylko odpowiedzi w języku niemieckim, ale jedyne wersje żądanego dokumentu, które serwer ma dostępny, są w języku angielskim lub francuskim.) Użycie go do wskazania brakującego parametru w żądaniu jest nieprawidłowe, zgodnie z definicją w specyfikacji.
Mark Amery
3

Dla zainteresowanych Spring MVC (przynajmniej 3.x) zwraca w tym przypadku 400, co wydaje mi się błędne.

Przetestowałem kilka adresów URL Google (accounts.google.com) i usunąłem wymagane parametry, które zazwyczaj zwracają 404 w tym przypadku.

Skopiowałbym Google.

Neromancer
źródło
18
Ponieważ Google tak nie oznacza, że ​​Google robi to dobrze!
rve
4
Zgadzam się, niekoniecznie „właściwe”, ale czasami to, co jest właściwe, a co rozsądne, to dwie różne rzeczy. W każdym razie .. do czytelnika :)
Neromancer
Niektóre interfejsy API Google zwracają wartość 400, np. Github.com/google/google-api-nodejs-client/issues/404
Dennis
co jest złe (i dlaczego wiosenny mvc nie jest zgodny z jax-rs)
jenson-button-event
3

Można argumentować, że 404 Not Foundnależy użyć a, ponieważ nie można znaleźć określonego zasobu.

Promień
źródło
3
Jest to domyślne zachowanie Java JAX-RS, gdy parametru zapytania nie można przekonwertować na odpowiedni typ danych. Jednak nie zgadzam się z tym. Zasób został znaleziony: parametry zapytania służą do filtrowania zasobu, a jeden z filtrów został dostarczony z niedopuszczalną wartością. Myślę, że odpowiada 422 najbliższym nieprzetworzonym jednostkom i 400 najbliższym błędnym żądaniom.
Ryan
jest to domyślne zachowanie jax-rs, ponieważ jest to właściwe zachowanie!
jenson-button-event
Użycie 404 jest uzasadnione, gdy parametr ciągu zapytania służy do identyfikacji zasobu, podano wartość, ale ta wartość nie odpowiada zasobowi, który istnieje - na przykład, jeśli żądasz example.com/show-user -profile? identyfikator_użytkownika = 123, a użytkownik 123 nie istnieje. Ale nie o to pytało to pytanie; chodziło o scenariusz, w którym wymagany parametr został całkowicie pominięty. Nie widzę, jak to odpowiada znalezieniu określonego zasobu.
Mark Amery
2

Często używam błędu 403 Forbidden. Powodem jest to, że prośba została zrozumiana, ale nie zrobię tego, o co poproszono (ponieważ coś jest nie tak). Jednostka odpowiedzi wyjaśnia, co jest nie tak, więc jeśli odpowiedzią jest strona HTML, komunikaty o błędach znajdują się na stronie. Jeśli jest to odpowiedź JSON lub XML, informacja o błędzie jest tam.

Od rfc2616 :

10.4.4 403 Zabronione

Serwer zrozumiał żądanie, ale odmawia jego spełnienia.
Autoryzacja nie pomoże, a prośba NIE POWINNA zostać powtórzona.
Jeśli metoda żądania nie była HEAD, a serwer chce podać do
publicznej wiadomości, dlaczego żądanie nie zostało spełnione, POWINIEN opisać przyczynę odmowy w jednostce. Jeśli serwer nie chce udostępnić tych informacji klientowi,
zamiast tego można użyć kodu stanu 404 (Nie znaleziono).

cdeszaq
źródło
4
Na początku brzmi dobrze, chociaż naturalnie kojarzę to z błędami uwierzytelniania lub uprawnień. Ponadto specyfikacja wskazuje na to, że „jeśli serwer nie chce udostępnić tych informacji klientowi”. Również 404 może być lepszym rozwiązaniem.
Kierowałbym się w
21
To okropny pomysł, nawet jeśli technicznie dobry. 403 jest powszechnie używany do reagowania na awarie uwierzytelniania, a zdezorientujesz klientów, jeśli spróbujesz użyć tego do wskazania błędów parametrów. Na przykład Twitter to robi - 403 jest używany zarówno wtedy, gdy podajesz nieprawidłowe dane uwierzytelniające OAuth, jak i gdy jest coś semantycznie niepoprawnego w twoim żądaniu - i jest to stałe źródło zamieszania dla klientów API.
Matt Zukowski,
1
@MattZukowski cóż, to po prostu źle. Specyfikacja mówi Authorization will not help, więc Twitter nie powinien wysyłać tego z powodu nieprawidłowych poświadczeń OAuth.
torvin
@torvin Twitter powinien 401 Unauthorizedzamiast tego wysyłać . Możesz jednak zrozumieć, dlaczego tak nie jest, jeśli spojrzysz na opisy tych dwóch kodów, które są bardzo podobne do dokumentów MDN .
Agi Hammerthief
-1

Aby użyć ASP.NET Core jako odniesienia lub przykładu, ASP.NET Core umożliwia rusztowanie kontrolera z akcjami, tak wygląda akcja „Szczegóły”.

    // GET: Cars/Details/5
    public async Task<IActionResult> Details(int? id)
    {
        if (id == null)
        {
            return NotFound();
        }

        var car = await _context.Cars.FirstOrDefaultAsync(m => m.CarId == id);
        if (car == null)
        {
            return NotFound();
        }

        return View(car);
    }

Jeśli parametr id nie jest ustawiony, zwraca 404 Not Found.

Fred
źródło
-5

Zwróć 404 - co oznacza, że ​​nie można znaleźć zasobu.

Spróbuj edytować adres URL witryny zawierającej identyfikator. Próbowałem kilka:

  • problem z repozytorium gitub
  • strona konfluencji
  • widok produktu Amazon
  • aukcja na eBayu
  • artykuł z wiadomościami BBC

Wszystkie zwracają 404, imo, ponieważ ci programiści poprawnie interpretują standard, czego nie ma tutaj odpowiedź i wiele innych!

jenson-button-event
źródło
1
Wierzę, że większość programistów definiuje „parametr” jako jedną z par nazwa / wartość w ciągu zapytania lub w treści formularza POST. Żądanie wydania repozytorium Github tego nie zawiera.
Kelvin,
@ Kelvin my devs uwzględniają również parametry ścieżki na liście. jeśli DOWOLNY parametr adresu URL jest obowiązkowy, reprezentuje lokalizację zasobu i nie jest uwzględniony, wówczas należy zwrócić 404. To wyklucza requestBody.
jenson-button-event
-6

Wybrałbym 403.

Z RFC 2616 - Hypertext Transfer Protocol - HTTP / 1.1

403 Zabronione

Serwer zrozumiał żądanie, ale odmawia jego spełnienia. Autoryzacja nie pomoże, a prośba NIE POWINNA zostać powtórzona. Jeśli metoda żądania nie była HEAD, a serwer chce podać do publicznej wiadomości, dlaczego żądanie nie zostało spełnione, POWINIEN opisać przyczynę odmowy w jednostce. Jeśli serwer nie chce udostępnić tych informacji klientowi, zamiast tego można użyć kodu stanu 404 (Nie znaleziono).

Powinieneś opisać przyczynę niepowodzenia w swojej odpowiedzi. Jeśli wolisz tego nie robić, po prostu użyj 404.

Francisco Costa
źródło
3
przegłosowano, ponieważ jest to duplikat odpowiedzi. Rozważ dodanie ostatniego zdania jako komentarza do starszej odpowiedzi, która oferuje użycie 403
użytkownik