[Poldek0000]

#humorinformatykow

[eloar]

@MarcinOrlowski: jak ja nienawidzę takich głupich API. Niby się powiodło, ale się #!$%@?ło. No i na dodatek 500... co mnie obchodzi twoje 500, weź się ogarnij i napraw swoje API. Ja wysłałem złe dane i Twoja usługa się poskładała? Czemu nie walidujesz danych na wejściu i nie odeślesz 400 tylko pozwalasz aby się usługa złożyła.

[Kroledyp]

@Poldek0000: Nie rozumiem ( ͡° ʖ̯ ͡°)

[MarcinOrlowski]

@R4vPL: Co ma RFC do tego ze nie uważam REST API za jedyne sluszne podejscie? Wystarczy Ci REST to sie trzymaj RFC i będziesz miał prościej + masę gotowych bibliotek. Ale nie zawsze API = REST API co jak widać nie dociera.
@EmcePomidor2: Oczywiscie ze ma znacznie czy to REST czy nie i to rzekłbym fundamentalne. Poza tym argument o nie istniejacej stronie jest całkowicie bez sensu. Zrobisz

[EmcePomidor2]

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

[MarcinOrlowski]

@EmcePomidor2: Ale wiesz ze jedno drugiego nie blokuje? ( ͡° ͜ʖ ͡°) IMHO dobrze zaprojektowane api ma podstawowa strukture odpowiedzi stała, czy to błąd czy Ok niektore pola sa zawsze. Ale jak ktos jakes pole dodaje do odpowiedzi bo jest błąd ale inaczej nie to jest to zwyczajnie gówniane API i tyle.

[eloar]

@MarcinOrlowski: wszystko co napisałem jest odpowiedzą na Twoje stanowisko, które zamieściłeś w tym komentarzu, dokładnie na słowa

No i prawidłowo

Nie, odpowiedź 200 z API po wystąpieniu błędu nie jest prawidłowa. Specyfikacja REST jest taka, że 200 ma oznaczać całkowicie poprawny przebieg. Każda odpowiedź z błędem oznacza konkretną sytuację, a body w odpowiedzi zawiera szczegóły. Jeśli tak projektujesz API, to nie ogarniasz prostego REST. Pewnie jeszcze projektujesz endpointy jak

[EmcePomidor2]

@MarcinOrlowski:

wiesz ze jedno drugiego nie blokuje? ( ͡° ͜ʖ ͡°)

ale wiesz że nie masz żadnej racji, przecież taki prosty kod nawet nie zadziała z twoim cudownym kodem 200 i trzeba jakieś ify i inne potwory trzaskać. po coś mądre głowy, mądrzejsze

[MarcinOrlowski]

@EmcePomidor2: ale wiesz ze poza JS i frameworkami których używasz są też inne sposoby w jakich możesz konsumować API?

[some_ONE]

@Poldek0000: Pomijając już sensowność takiego rozwiązania to mam bekę jak niektórzy myślą, że HTTP == REST (to samo widać tutaj w komentarzach) i według nich każde api wystawione po HTTP musi być RESTowe.

Gdzie prawda jest taka, że w większości przypadków jak wystawiasz API tylko na potrzeby swojego frontu (teraz przecież każdy musi wystawiać API bo front pisze w SPA ( ͡° ͜ʖ ͡°)) to nie

[EmcePomidor2]

@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/sh

[DooBeeDooBee]

@draxgar:

źle op. Doucz się. Odpowiedź REST ma stosować poprawne nagłówki HTTP

Sam się doucz xD Dokument RFC który linkujesz nie ma statusu standardu a jest jedynie propozycją. Istnieje kilka różnych wersji takich dokumentów. Statusy HTTP nigdy nie były jakoś specjalnie przemyślane i to jak ich używać większości z nich jest zostawione wyobraźni programistów. GraphQL np. zawsze zwraca 200 i też jest spoko.

W tym momencie nie ma ŻADNEGO oficjalnego

[LebronAntetokounmpo]

@iAmTS: co to za jakieś bzdury z Utah Jazz??

[Poldek0000]

@MarcinOrlowski: jak ja nienawidzę takich głupich API. Niby się powiodło, ale się #!$%@?ło. No i na dodatek 500... co mnie obchodzi twoje 500, weź się ogarnij i napraw swoje API. Ja wysłałem złe dane i Twoja usługa się poskładała? Czemu nie walidujesz danych na wejściu i nie odeślesz 400 tylko pozwalasz aby się usługa złożyła.

@eloar: życia nie znasz? Jeśli klient dla firmy jest strategiczny to ma zawsze

[i.....S]

@some_ONE: no tak, ja założyłem oczywiście publiczne API. Wewnętrzne często mają to w piździe - tylko najgorrzej jak ktoś potem wpada na genialny pomysł wystawienia tego api xD Weź to przerabiaj albo ucz użytkownika swojego cudownego standardu, bo przeciez nie musiało być restowe :)

[some_ONE]

tylko najgorrzej jak ktoś potem wpada na genialny pomysł wystawienia tego api

@iAmTS: No cóż, wtedy trzeba sprawę postawić jasno - wewnętrzne api nie nadaje się do wystawienia publicznego.
Sam sposób uwierzytelniania będzie pewnie całkiem inny.

[a.....r]

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

[some_ONE]

@adibor: gay wizard? ( ͡° ͜ʖ ͡°)

[i.....S]

@some_ONE: to samo z OpenAPI, panie po co takie gówna, sami będziemy dokumentować nasze api, małe będzie, nikt nie będzie na tyle używać, itd.

Rok mija i #!$%@? musisz sam pisać dokumentację do requestów i nie masz generatorów, endpointy są #!$%@? a użytkownik musi czytać twoje książki xD

[K-S-]

@Poldek0000: Ale po co zgłaszać błędy? Działa to działa nie działa to błąd po stronie frontu, zresztą robię zlecenie i tyle mnie widzieli ¯\_(ツ)_/¯

[MarcinOrlowski]

@EmcePomidor2: i czego niby dowodzi twoj skrypcik? tego ze przykryłeś potencjalny problem HTTP i zeby faktycznie ustalić co poszlo nie tak, to jednak i trzeba trochę więcej kodu napisać niż wyświetlić glupkowaty komunikat "pa mati 2001" i pora na CS? Sam kod HTTP zwyczajnie nic konkretnego Ci i tak nie powie, powinienes to wiedziec. Ify i tak trzaskać musisz chyba ze naiwnie oczekujesz ze kod bledu zawiera payload a jak