Jakie statusy http dla usługi

Witam

Załóżmy że chciałbym mieć usługę (1), która przyjmuje JSONa z danymi z formularza (frontend po kliknięciu przycisku przez zalogowanego użytkownika wyśle dane). Dla większości użytkowników wykona się i zwróci poprawne wykonanie. Jednak czasem, jak ktoś przekroczy dużą liczbę wywołań, to chciałbym mu dodatkowo wyświetlić kod autoryzacyjny, który wyśle się na maila. Frontend powinien wtedy wyświetlić okienko do wpisania kodu i ponownie wysłać formularz razem z kodem na inną usługę (2), która sprocesuje dane i ustawi flagę użytkownikowi że już nie musi się potwierdzać (czyli dalej może używać (1)). Informacja o kodzie byłaby zwracana przez backend na odpowiedź do (1).
Pytanie - jakie statusy powinien zwracać backend na usługę (1):
a) gdy od razu przetworzono
b) gdy trzeba jeszcze wpisać kod

W a 200 OK będzie OK:), a w b widzę dwie opcje:

202?

The HTTP 202 Accepted successful response status code indicates that a request has been accepted for processing, but processing has not been completed or may not have started. The actual processing of the request is not guaranteed; a task or action may fail or be disallowed when a server tries to process it.

A może 403?

The HTTP 403 Forbidden client error response status code indicates that the server understood the request but refused to process it. This status is similar to 401, except that for 403 Forbidden responses, authenticating or re-authenticating makes no difference. The request failure is tied to application logic, such as insufficient permissions to a resource or action.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403

Jest jeszcze drugie podejście, może zaraz pojawić się mocna gównoburza, ale napiszę. Część ludzi uważa, że to jest dobre, część że to prowizorka i masakryczna zbrodnia ;)

Ogólnie w takiej sytuacji, jeśli komunikacja z serwerem poszła OK, to dajesz ZAWSZE kod 200 - bo oznacza, że żądanie zostało przetworzone pozytywnie, udało się dobić do serwera, on zrozumiał o co chodzi, przetworzył (w jakikolwiek sposób) żądanie, wysłał odpowiedź. A szczegóły odnośnie tego, co serwer ma do przekazania na front (albo gdziekolwiek indziej - np. do aplikacji mobilnej) przesyłasz wewnątrz odpowiedzi - czy jakiś JSON, czy jakkolwiek inaczej zapakowane.

Nie chcę teraz nikogo triggerować, wiem że wiele osób uważa to za coś gorszego od rasizmu i nazizmu, ale w sumie... to Twoja apka, Ty decydujesz jak zrobisz. Jeśli Tobie takie coś pasuje to jedź śmiało. Dla mnie takie podejście jest OK - status HTTP oznacza tylko tyle, że moje zapytanie dotarło do serwera i zostało przetworzone, a co serwer konkretnie miał do przekazania mam już w treści/ciele odpowiedzi.

To trochę jak z pismem z odpowiedzią z urzędu - dostajesz list w kopercie (czyli odpowiednik otrzymania kodu 200), a w środku koperty jest dokument, którego treść jest właściwą odpowiedzią na złożone zapytanie. Możesz dostać zarówno zgodę na to, o co wnioskowałeś (czyli odpowiednik kodu 200), odmowę (czyli np. 403) albo wezwanie do złożenia wyjaśnień/uzupełnienia braków (odpowiednik kodu np. 300). Plusem jest też to, że w takim wariancie nie musisz się ograniczać i dopasowywać do istniejących kodów http, ale stworzyć swoje odpowiedzi, które będą dokładnie dopasowane do tego, czego potrzebujesz - dokładnie tak, jak wynika to z logiki działania aplikacji. A później, jeśli pojawi się potrzeba dodania nowego scenariusza/innego zachowania, to po porostu dodajesz kolejny wariant.

@cerrato To też jest jedno z dobrych podejść, po prostu odejść od REST'a i używać HTTP tylko jako wartstwy transportowej, wysyłać tylko 200, nawet do errorów. Jakby nie patrzeć, nie tworzysz serwera HTTP, tworzysz swoją aplikację. Błąd w aplikacji nie koniecznie jest błedem HTTP.

To też jest jedno z dobrych podejść, po prostu odejść od REST'a i używać HTTP tylko jako wartstwy transportowej

Dokładnie, ja uważam tak samo - używam http do przesyłania treści i dla mnie kod 200 oznacza, że komunikacja z serwerem poszła OK i dostałem jakąkolwiek odpowiedź, a to, co konkretnie serwer miał do powiedzenia mam już w ciele samej odpowiedzi.

Szczerze mówiąc - nigdy nie lubiłem REST, nie trafiało to do mnie. Ale też wiem, że wiele osób czegoś takiego nie akceptuje - stąd obawa, czy zaraz nie zacznie się ostra zadyma w tym wątku :D

cerrato napisał(a):

Szczerze mówiąc - nigdy nie lubiłem REST, nie trafiało to do mnie. Ale też wiem, że wiele osób czegoś takiego nie akceptuje - stąd obawa, czy zaraz nie zacznie się ostra zadyma w tym wątku :D

Ale chwila, nie idźmy w drugą skrajność. Jak mamy układ, np. przeglądarka <-> nginx <-> aplikacja, to kody błędu są pomocne na drodze "przeglądarka <-> nginx". Ale nie oznacza to ofc. że odpowiedzi aplikacji muszą się dopasować do HTTP.