[Poldek0000]

#humorinformatykow

[lycaon_pictus]

@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.

[MarcinOrlowski]

@Poldek0000: No i prawidłowo. Komunikacja po HTTP przebiegła OK, wiec 200 się należy jak najbardziej. Sama odpowiedz powinna zawirać wszystko co trzeba zeby ustalić czy polecnie (nie request HTTP) się powiódł. No ale jak ktoś nasłuchał się bzdur na bootcampach i uwierzył że odpowiedz API trzeba koniecznie powiązać z transportem to potem robi minę jak zielony grubas ¯\_(ツ)_/¯

[draxgar]

@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

[Bauzzer]

@MarcinOrlowski:

[Haziux]

@MarcinOrlowski no i kto tu był na bootcampie xd

[Kresse]

@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

[Poldek0000]

@lycaon_pictus: @Kresse: @iAmTS:
Wszyscy macie rację i jednocześnie się mylicie! Wszystko zależy 'od specyfikacji i życzenia klienta' ;-)

[Owlosiaty-Dzik]

@MarcinOrlowski: @draxgar: @iAmTS:
dobry artykuł:
https://blog.slimjim.xyz/posts/stop-using-http-codes/

[lycaon_pictus]

@Poldek0000:

Wszyscy macie rację i jednocześnie się mylicie! Wszystko zależy 'od specyfikacji i życzenia klienta' ;-)

Nie, to po prostu stażyści robili kopiuj-wklej i wysyłali wszędzie OK, zamiast Bad Request.

[MarcinOrlowski]

@draxgar: Jeśli jedyne API z ktorym pracowałeś do tej pory to REST to pewnie. Ale przyjdzie biznes i zapragnie mieć wasze serwisy wystawione także innymi kanałami (np. via FTP czy po mailu) to szybko się zaczniesz drapać po głowie na h** ci ten REST był. Ale co ja tam wiem...

[w222]

@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

[Wap30]

Komunikacja po HTTP przebiegła OK

@MarcinOrlowski: poza tym, że wywołała wewnętrzny błąd serwera ( ͡° ͜ʖ ͡°) W takim razie komunikacja po jakim protokole przebiegła niepoprawnie? REST nie jest protokołem, ostatni protokół w obrębie którego wystąpił błąd to właśnie HTTP

[MarcinOrlowski]

@Wap30: Tyle ze musialbyś się postarać zeby w miejsce 500 zwrócić 200 a to już pod sabotaż by się chyba nawet dało podciągnąc :)

[Kresse]

@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.

[Wap30]

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 HTTP

[dwugitofenobezlikusensolikum]

Odpowiedź REST

@draxgar: a skąd wiesz, że tu jest użyty REST?

[aka-mikado]

@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.

[R4vPL]

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

[EmcePomidor2]

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