Kiedy zwrócić 404 a kiedy 200 (czy tam 204 może)

Cześć,

wdałem się w ciekawą dyskusję gdzie potoczyło się o to, jaki kod response powinien być zwrócony w takim scenariuszu.

Serwis A za pomocą RestApi uderza do serwisu B aby coś znaleźć. Serwis B zwraca 404 bo np. nie ma zasobu w bazie. Więc A dostał na twarz 404 i pytanie, co A ma zwrócić na front ? W implementacji którą widziałem developer zwrócił kod 200.

I tutaj zaczęła się dyskusja, moim zdaniem może i to troche dziwnie wygląda, ale zwrócenie tutaj 200 nie jest błędem. Z kolei, jest spora grupa zwolenników tego, że trzeba koniecznie zwróci 404. Mi zwracanie tutaj 404 bardzo nie pasuje, bo de facto - jest to przenoszenie błędów/informacji o nich - innego serwisu (B w tym wypadku) do serwisu A. A jestem przeciwny rozlewania się odpowiedzialności serwisów na kilka na raz, tutaj jak muszę robić taką głupią przerzutkę z B do A i na front, to czuje że tak naprawdę to jest komunikacja frontu z B a ten serwis A jest bez sensu.

Z kolei, serwis A dostając od B 404, działa poprawnie, nic się nie wywala, nie odpala się jakaś alternatywna logika itd itp.

Pytanie, jak wy byście to ograli? Być może 204 jest tutaj rozwiązaniem wszystkich wątpliwości?

ps. Brak większego kontekstu biznesowego, developer kończąc zadanko musiał zdecydować się na jakiś kod.

Trochę zależy od sytuacji. 404 jest właściwe jeśli tym zasobem jest np. artykuł, wątek na forum, czy cokolwiek co zostało jednoznacznie określone. Natomiast jeśli było to wyszukiwanie, które może zwrócić wiele wyników, ale nie znalezienie tego zasobu jest normalną sytuacją to powinno być 200 z odpowiednim komunikatem. Jak mówi dokumentacja: The HTTP 200 OK success status response code indicates that the request has succeeded. A 200 response is cacheable by default.. Wyszukiwanie powiodło się z brakiem wyników, ale nieznalezienie konkretnie wywołanego zasobu już można nazwać błędem, który zasługuje na 404.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
Tu czytamy, że 204 jest zarezerwowane dla sytuacji, w której przeglądarka ma nie przechodzić do innej strony tylko pozostać na obecnej. Tak więc przypuszczam, że to nie jest to czego potrzeba w tej sytuacji, bo chyba chcemy poinformować użytkownika, że nic nie znaleziono…

Jeśli faktycznie twój serwis może sensownie zrealizować żądanie mimo, że inny serwis rzuca 404 - to faktycznie 200 jest moim zdaniem najbardziej sensowna.

A w ogólności:
Dywagacje na temat kodu błędu i bycia bardziej RESTowym to zwykle strata czasu. Nawet jak osiągniesz rest maturity level 3 to nikt za to Ci nie da medalu, serio, nikt tego nie sprawdza i się nie przejmuje.
Doputy nie robisz czegoś tak dziwnego, że np. błędy zwracasz jako 101 a sukces jak 666 to naprawdę nie ma problemu.
Możesz mieć zawsze 200. Możesz zwracać 404.

Serwis A za pomocą RestApi uderza do serwisu B aby coś znaleźć. Serwis B zwraca 404 bo np. nie ma zasobu w bazie. Więc A dostał na twarz 404 i pytanie, co A ma zwrócić na front ? W implementacji którą widziałem developer zwrócił kod 200.

Ten przykład jest tak ogólny, że w sumie nie wiadomo o co chodzi, i każda odpowiedź może być prawidłowa. Czy w każdym przypadku wywołania front -> a -> b -> ... należy propagować każdy błąd HTTP w górę stosu (pomijając, że taka architektura raczej nie jest sensowna)? Oczywiście że nie. Co oznacza to 404? Mam wrażenie, że uznajesz to za błąd w systemie. A to nie musi być błąd - co jeśli odpytuję serwis cache o dane o userze id=123 -> status 404 znaczy brak danych, to nie jest "błąd". Brak czegoś nie musi być błędem.

2 rady:

1. jeśli to API jest publiczne i jest konsumowane przez 100000 innych aplikacji (np. API Allegro - strzelam - choć tutaj raczej to boty), to warto się takimi rzeczami przejmować, w przeciwnym przypadku - gdy konsumentem API jest (jak to powiedział Sobótka) "zespół z pokoju obok" - olej to i się nie przejmuj, rzuć kostką jak nie możesz się zdecydować
2. zapnij monitoring na statusy HTTP zwracane przez serwisy - fajnie to działa w Springu + Prometheus - będziesz musiał zwrócić uwagę na semantykę 200/404, jak ci dashboardy na czerwono będą walić błędami, a przecież wszystko działa.

Wszystko zależy od przypadku biznesowego.

• Jeśli ktoś kto korzysta z A dostał zasób jaki chciał, to powinno być 200.
• Jeśli ktoś kto korzysta z A nie dostał zasobu, to wtedy powinno być 404.

Odpowiedź z B nie ma żadnego znaczenia.

API nie powinno być zależne od implementacji.
To że pod spodem, w implementacji coś zwraca 404 nie musi nas wiele obchodzić, nawet jakby zwrócił 500 ale był fallback to może się to skończyć pomyślną odpowiedzią.
Liczy się tylko zachowanie wyspecyfikowane przez API.

Plus pamiętajmy, że może być przyjętę np. podejście zwracania zawsze 200 mimo błędu na backendzie z po prostu dorzuconym jakimś obiektem error/errorCode w odpowiedzi (nie jestem do tego jakoś turbo przekonany ale spotkałem się z czymś takim w projekcie)

RequiredNickname napisał(a):

Plus pamiętajmy, że może być przyjętę np. podejście zwracania zawsze 200 mimo błędu na backendzie z po prostu dorzuconym jakimś obiektem error/errorCode w odpowiedzi (nie jestem do tego jakoś turbo przekonany ale spotkałem się z czymś takim w projekcie)

Kiedyś się z takiego podejścia śmiałem, aż do czasu kiedy jakiś źle ustawiony URL czy źle skonfigurowane proxy spowodowało zwracanie 404, co było interpretowane jako brak danego zasobu (i tak, to był problem, bo przez to robiły się duplikaty np. transakcji finansowych)