200
Ugh ... (309, 400, 403, 409, 415, 422) ... wiele odpowiedzi próbuje zgadnąć, argumentować i ustandaryzować najlepszy kod powrotu dla udanego żądania HTTP, ale nieudane wywołanie REST .
Jest źle mieszać kody stanu HTTP i kody stanu spoczynku.
Widziałem jednak wiele implementacji mieszających je i wielu programistów może się ze mną nie zgodzić.
Kody zwrotne HTTP są powiązane z samym HTTP Requestsobą. Wywołanie REST jest wykonywane przy użyciu żądania protokołu przesyłania hipertekstu i działa na niższym poziomie niż sama wywołana metoda REST. REST jest koncepcją / podejściem, a jego wynik jest wynikiem biznesowym / logicznym , podczas gdy kod wyniku HTTP to transportowym .
Na przykład zwracanie „404 Nie znaleziono”, gdy dzwonisz / users /, jest mylące, ponieważ może to oznaczać:
- Niepoprawny identyfikator URI (HTTP)
- Nie znaleziono użytkowników (REST)
„403 Zabroniony / Odmowa dostępu” może oznaczać:
- Potrzebne specjalne pozwolenie. Przeglądarki mogą sobie z tym poradzić, pytając użytkownika / hasło. (HTTP)
- Niepoprawne uprawnienia dostępu skonfigurowane na serwerze. (HTTP)
- Musisz być uwierzytelniony (REST)
Lista może być kontynuowana z błędem „500 Server error” (błąd rzucenia HTTP Apache / Nginx lub błąd ograniczeń biznesowych w REST) lub innymi błędami HTTP itp.
Na podstawie kodu trudno zrozumieć, co było przyczyną niepowodzenia, awarii HTTP (transportu) lub awarii REST (logicznej).
Jeśli żądanie HTTP zostało fizycznie wykonane pomyślnie, zawsze powinno zwrócić kod 200, niezależnie od tego, czy rekord (y) został znaleziony, czy nie. Ponieważ zasób URI został znaleziony i był obsługiwany przez serwer HTTP. Tak, może zwrócić pusty zestaw. Czy można otrzymać pustą stronę internetową z wynikiem 200 jako HTTP, prawda?
Zamiast tego możesz zwrócić 200 kod HTTP z kilkoma opcjami:
- obiekt „error” w wyniku JSON, jeśli coś pójdzie nie tak
- Opróżnij tablicę / obiekt JSON, jeśli nie znaleziono rekordu
- Flaga wyniku bool / sukces w połączeniu z poprzednimi opcjami dla lepszej obsługi.
Ponadto niektórzy dostawcy Internetu mogą przechwytywać żądania i zwracać kod 404 HTTP. Nie oznacza to, że twoich danych nie znaleziono, ale na poziomie transportu coś jest nie tak.
Z Wiki :
W lipcu 2004 r. Brytyjski dostawca usług telekomunikacyjnych BT Group wdrożył system blokowania treści Cleanfeed, który zwraca błąd 404 w przypadku każdego żądania treści zidentyfikowanych przez Internet Watch Foundation jako potencjalnie nielegalne. W tych samych okolicznościach inni dostawcy usług internetowych zwracają błąd „zabronione” HTTP 403. Praktyka stosowania fałszywych błędów 404 jako sposobu na ukrycie cenzury została również zgłoszona w Tajlandii i Tunezji. W Tunezji, gdzie przed rewolucją w 2011 r. Cenzura była poważna, ludzie zdali sobie sprawę z natury fałszywych błędów 404 i stworzyli wymyśloną postać o imieniu „Ammar 404”, która reprezentuje „niewidzialnego cenzora”.
Dlaczego nie po prostu odpowiedzieć na coś takiego?
{
"result": false,
"error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}
Google zawsze zwraca 200 jako kod stanu w interfejsie API Geokodowania, nawet jeśli żądanie logicznie się nie powiedzie: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes
Facebook zawsze zwraca 200 za pomyślne żądania HTTP, nawet jeśli żądanie REST nie powiedzie się: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling
To proste, kody stanu HTTP są dla żądań HTTP. Interfejs API REST należy do Ciebie, zdefiniuj kody stanu.