@MarcinOrlowski: źle op. Doucz się. Odpowiedź REST ma stosować poprawne nagłówki HTTP (pewnie dlatego, że jest PO HTTP), poczytaj sobie https://www.rfc-editor.org/rfc/rfc7807#section-3

@MarcinOrlowski:

@MarcinOrlowski no i kto tu był na bootcampie xd

Komunikacja po HTTP przebiegła OK, wiec 200 się należy jak najbardziej

@MarcinOrlowski: super ale żądanie klienta wcale nie przebiegło OK, weź się ogarnij, nie ma znaczenia czy to REST czy nie, przecież po to są te kody

jak strona nie istnieje to walisz też 200 bo komunikacja przebiegła ok? xD

@Owlosiaty-Dzik: blog losowego typa założony w 2021 to jest taki średni sos.
Jak już chcesz się na kimś wzorować to chyba lepiej na https://cloud.google.com/apis/design/errors

@Poldek0000: A weź. Ja miałem kiedyś takie API, że dostałem dokumentację z wytycznymi, bo jak wysłałeś złe dane to odpisywał, że 200, ale nie odsyłał błędu i tylko widziałeś, że w getach dostajesz nieaktualne dane.

@Owlosiaty-Dzik: Niby jest to jakis argument, ale nic nie stoi na przeszkodzie, zeby do 404 dolaczyc JSONa wyjasniajacego blad. Poza tym parsowanie takiego responsa, ktory moze byc bledem lub encja jest o wiele bardziej upierdliwe. Lwia wiekszosc frameworkow promuje tradycyjne podejscie, gdzie 4xx i 5xx po prostu sa traktowane jako wyjatki.

error reporting oparty jest wyłącznie na kodach HTTP to chyba cos tu nie halo.

@MarcinOrlowski: ale wiesz że oprócz kodu 500 można wysyłać content? ( ͡° ͜ʖ ͡°)

Zrobisz typo w adresie endpointu to tez dostaniesz 404

ale według ciebie to bez sensu przecież komunikacja się powiodła ( ͡° ͜ʖ ͡°) 200 się należy

dobry artykuł

@Owlosiaty-Dzik: artykuł, jak autor sam opisuje, skupia się na RPC, a przykłady daje z typowych RESTowych resourców, i jeszcze zakłada że identyfikator zasobu nie jest częścią ścieżki. Niby jakim cudem to dobry artykuł?

"I’m not talking about a RESTful service, but rather HTTPPokaż całość

@Poldek0000: Raz dostałem takie API od SAP. Też zwracali zawsze 200, a w przypadku błędu dodawali specjalny nagłówek w którym był JSON opisujący błąd xD

@MarcinOrlowski poczytaj RFC albo chociaż opracowania dotyczące HTTP od Mozilli, a nie siejesz głupoty.

@Owlosiaty-Dzik: trudno sie zgodzic z tezami tego bloga:
No such employee /api/v1/employees/100 - 404 z jsonem, bo co stoi na przeszkodzie?
Bad path /api/v11/employees/1 - 400 bo url niepoprawny i basta

po co kombinowac z przykrywaniem bledow 200?

poza tym juz widze pieklo monitorowania czegos takiego za pomoca prometheusa... wszedzie 200.

@MarcinOrlowski: tu nie chodzi jaki język używam, kody są żeby sobie życie ułatwiać a nie wymyślać od nowa

kuźwa no curlem sobie w terminalu strzel i dzięki temu że masz kod 500 to będziesz miał exit code <> 0

#!/bin/shPokaż całość

@Poldek0000: prawie jak wypok, gdzie każdy błąd po stronie serwera zwracany jest jako 'trwa aktualizacja serwisu'.