Czy powinienem używać kodów stanu HTTP do opisywania zdarzeń na poziomie aplikacji

Kilka serwerów, z którymi miałem do czynienia, zwróci HTTP 200 dla żądań, które klient powinien rozważyć jako błąd, z czymś w rodzaju „sukces: fałsz” w treści.

Nie wydaje mi się to prawidłową implementacją kodów HTTP, szczególnie w przypadku nieudanego uwierzytelnienia. Przeczytałem kody błędów HTTP dość zwięźle podsumowane, ponieważ „4xx” oznacza, że ​​żądanie nie powinno zostać wykonane ponownie, dopóki nie zostanie zmienione, a „5xx” oznacza, że ​​żądanie może być lub może nie być prawidłowe i może zostać ponowione, ale nie powiodło się. W tym przypadku 200: logowanie nie powiodło się lub 200: nie można znaleźć tego pliku lub 200: brak parametru x, zdecydowanie wydaje się nieprawidłowy.

Z drugiej strony widziałem argument, że „4xx” powinien wskazywać jedynie na problem strukturalny z żądaniem. Warto więc zwrócić 200: zły użytkownik / hasło zamiast 401 nieautoryzowanych, ponieważ klient może złożyć żądanie, ale zdarza się, że jest niepoprawny. Argument ten można podsumować, ponieważ jeśli serwer byłby w stanie przetworzyć żądanie i w ogóle ustalić, kod odpowiedzi powinien wynosić 200, a to od klienta zależy sprawdzenie treści w celu uzyskania dalszych informacji.

Zasadniczo wydaje się to być kwestią preferencji. Ale to nie jest satysfakcjonujące, więc jeśli ktoś ma powód, dla którego któryś z tych paradygmatów jest bardziej poprawny, chciałbym wiedzieć.

Interesujące pytanie.

Zasadniczo możemy sprowadzić to do właściwego sposobu klasyfikowania rzeczy w kategoriach analogicznych do warstw OSI. HTTP jest powszechnie definiowany jako protokół poziomu aplikacji, a HTTP jest rzeczywiście ogólnym protokołem klient / serwer.

Jednak w praktyce serwer jest prawie zawsze urządzeniem przekazującym, a klient jest przeglądarką internetową, odpowiedzialną za interpretację i renderowanie treści: serwer po prostu przekazuje rzeczy do dowolnej aplikacji, która wysyła dowolne skrypty, które przeglądarka przegląda jest odpowiedzialny za wykonanie. Sama interakcja HTTP - formularze żądania / odpowiedzi, kody stanu itd. - to głównie kwestia tego, jak żądać, obsługiwać i renderować dowolne treści tak skutecznie, jak to możliwe, bez przeszkadzania. Wiele kodów stanu i nagłówków jest rzeczywiście zaprojektowanych do tych celów.

Problem z próbą nałożenia protokołu HTTP na obsługę przepływów specyficznych dla aplikacji polega na tym, że masz jedną z dwóch opcji: 1) Musisz ustawić logikę żądania / odpowiedzi jako podzbiór reguł HTTP; lub 2) Musisz ponownie zastosować określone zasady, a następnie rozdzielenie obaw zwykle się rozmywa. Na początku może to wyglądać ładnie i czysto, ale myślę, że jest to jedna z tych decyzji projektowych, których żałujesz w miarę rozwoju projektu.

Dlatego powiedziałbym, że lepiej jest wyraźnie powiedzieć o rozdzieleniu protokołów. Pozwól, aby serwer HTTP i przeglądarka internetowa zrobiły swoje, a aplikacja niech zrobi to samo. Aplikacja musi być w stanie wysyłać żądania i potrzebuje odpowiedzi - a jej logika dotycząca sposobu żądania, interpretowania odpowiedzi może być bardziej (lub mniej) złożona niż perspektywa HTTP.

Inną zaletą tego podejścia, o której warto wspomnieć, jest to, że aplikacje zasadniczo nie powinny zależeć od podstawowego protokołu transportowego (z logicznego punktu widzenia). Sam HTTP zmienił się w przeszłości, a teraz uruchamiamy HTTP 2, po SPDY. Jeśli widzisz swoją aplikację jako zwykłą wtyczkę funkcjonalną HTTP, możesz utknąć w niej, gdy przejmą ją nowe infrastruktury.

To pytanie jest nieco oparte na opiniach, ale tak czy inaczej.

Z mojego punktu widzenia 200 może podawać „miękkie błędy”. Jeśli chodzi o tworzenie interfejsów API, staram się rozróżniać te od „twardych błędów”.

„Błędy miękkie” będą wyświetlane z kodem stanu 200, ale będą zawierać opis błędu i status powodzenia false. „Miękkie błędy” pojawią się tylko wtedy, gdy wynik będzie „zgodny z oczekiwaniami”, ale nie będzie to sukces w ścisłym tego słowa znaczeniu.

Należy zauważyć, że „błędy miękkie” są raczej wskazówką dla implementatora. Dlatego ważne jest, aby podać także więcej informacji o błędzie, takich jak czytelny dla człowieka komunikat o błędzie i / lub jakiś kod, który może być użyty do przekazania użytkownikowi końcowemu informacji zwrotnej. Te błędy dostarczają implementatorowi (i użytkownikowi końcowemu) więcej informacji o tym, co wydarzyło się po stronie serwera rzeczy.

Powiedzmy na przykład, że masz interfejs API z funkcją wyszukiwania, ale podczas wyszukiwania nie są wyświetlane żadne wyniki. Nie jest to błędne, ale też nie jest „sukcesem”, nie w najściślejszym znaczeniu definicji.

Przykład sformatowany jako JSON:

{
    "meta" {
        "success": false,
        "message": "Search yielded no results",
        "code": "NORESULTS"
    }
    "data": []
}

Z drugiej strony „twarde błędy” otrzymają kod statusu zalecany dla błędu. Użytkownik nie jest zalogowany? - 403 / 401. Zniekształcone dane wejściowe? - 400. Błąd serwera? - 50X. I tak dalej.

Ponownie, jest to trochę oparte na opiniach. Niektórzy ludzie chcą traktować wszystkie błędy jednakowo, „twardy błąd” wszystko. Brak wyników wyszukiwania? To 404! Po drugiej stronie monety nie ma wyników wyszukiwania? - Jest to zgodne z oczekiwaniami, bez błędu.

Innym ważnym czynnikiem, który należy wziąć pod uwagę, jest na przykład twoja architektura; jeśli korzystasz z interfejsu API za pomocą zapytań JavaScript XHR i jQuery lub AngularJS. Te „twarde błędy” będą musiały być obsługiwane za pomocą osobnego wywołania zwrotnego, podczas gdy „miękkie błędy” mogą być obsługiwane za pomocą wywołania „powodzenia”. Nic nie psując, wynik jest nadal „zgodny z oczekiwaniami”. Kod po stronie klienta może następnie sprawdzić status powodzenia i kod (lub komunikat). I wydrukuj to użytkownikowi końcowemu.

Istnieją dwa aspekty interfejsu API: wysiłek wdrożenia interfejsu API i wysiłek wszystkich klientów w celu prawidłowego korzystania z interfejsu API.

Jako autor klienta wiem, że kiedy wysyłam zapytanie do serwera WWW, mogę otrzymać błąd (nigdy nie rozmawiał poprawnie z serwerem) lub odpowiedź z kodem stanu. Muszę poradzić sobie z błędami. Muszę sobie poradzić z dobrą reakcją. Muszę sobie radzić z oczekiwanymi, udokumentowanymi „złymi” odpowiedziami. Muszę sobie poradzić z tym, co jeszcze wróci.

Projektując interfejs API, powinieneś sprawdzić, co jest najłatwiejsze do przetworzenia przez klienta. Jeśli klient wysyła poprawnie sformułowane żądanie i możesz zrobić to, o co prosi żądanie, powinieneś udzielić odpowiedzi w zakresie 200 (w niektórych przypadkach odpowiednia jest liczba inna niż 200 w tym zakresie).

Jeśli klient zapyta „daj mi wszystkie rekordy, takie jak ...”, a jest zero, to 200 z sukcesem i tablica zerowych rekordów jest w pełni odpowiednia. Przypadki, o których wspominasz:

„Logowanie nie powiodło się” zwykle powinno wynosić 401. „Nie można znaleźć pliku” powinno wynosić 404. „Brak parametru x” powinien wynosić około 500 (właściwie 400, jeśli serwer stwierdzi, że żądanie jest złe, a 500 jeśli serwer jest całkowicie zdezorientowany moim żądaniem i nie ma pojęcia, co się dzieje). Zwrócenie 200 w tych przypadkach jest bezcelowe. Oznacza to po prostu, że jako autor klienta nie mogę po prostu patrzeć na kod statusu, muszę też przestudiować odpowiedź. Nie mogę po prostu powiedzieć „status 200, świetnie, oto dane”.

Zwłaszcza „brak parametru” - nie jest to coś, z czym bym sobie poradził . To znaczy, że moja prośba jest nieprawidłowa. Jeśli moje żądanie jest niepoprawne, nie mam możliwości naprawy tego niepoprawnego żądania - na początek wysłałbym prawidłowe żądanie. Teraz jestem zmuszony to znieść. Dostaję 200 i muszę sprawdzić, czy brakuje odpowiedzi „parametru”. To okropne.

W końcu istnieje kilkanaście lub dwa kody stanu do obsługi wielu różnych sytuacji i należy ich używać.