[Poldek0000]

#humorinformatykow

[EmcePomidor2]

@MarcinOrlowski: dowodzi tego że z kodami nawet taki prosty skrypcik by działał bardzo dobrze w 100%

200 = OK zwiększyłem licznik, inny status = jakieś błędy i mogę sobie wtedy debugować

to jednak i trzeba trochę więcej kodu napisać

no, w drugiej linijce dopisać >> debug.log
xD

Sam kod HTTP zwyczajnie nic konkretnego Ci i tak nie powie, powinienes to wiedziec

oczywiście, przecież to ja ci wyżej tłumaczyłem że oprócz statusu

[draxgar]

@Owlosiaty-Dzik: artykuł, opinia. Ja mówię o specyfikacji. Z opinią jest jak z dupą, każdy ma swoją. Specyfikacja to kontrakt, którego powinieneś używać.
Moje doświadczenia z TomTom mówią, że skoro to specyfikacja, wszyscy *spodziewają się* że będzie przestrzegana. Nawet jeśli sami tego nie stosowali ;-)

wszyscy się mylicie, żaden z was nie ma racji

Nie wyraziłem opinii, by się mylić. Skierowałem cię tylko do źródeł specyfikacji. Akurat moja opinia nie ma tu

[V.....e]

Boże ale ciężki przypadek wam się trafił xd

[MarcinOrlowski]

@EmcePomidor2: Ja mam wrażenie ze Ty i pozostali myślą że jak dostaną status 200 to już nie wolno zaglądać do payloadu i sprawdzać czy np. "success" == true bo będzie linijką po łapach albo dyscyplinarka i w ogóle apage, szatan. Jałowa debata.

[wojciech-wwww]

@aka-mikado: jak ostatnio prezentowałem na callu jak to aplikacja działa zajebiście bo od miesiąca tylko same 200. Po czym po callu odkryłem że błędy też są zwracane ze statusem 200 XD. Czasem jak widzę takie kwiatki to się zastanawiam skąd ludzie biorą takie praktyki, przecież to jest tak głupie że aż szkoda działać.

[wojciech-wwww]

@MarcinOrlowski: a jak robisz testy to też robisz żeby świeciły się na zielono, nawet jak test nie przejdzie? To jest ten sam poziom absurdu

[skarpetyodyna]

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 ¯_(ツ)_/¯

@MarcinOrlowski: mam nadzieję, że nigdy nie spotkam podobnych nie-bootcampowców na swojej biznesowej drodze xD

[aka-mikado]

konkludujac:
- zwracanie 200 przy bledzie jest ok, bo graphql: "task failed successfully"
- jakies specyfikacje i wytyczne, RFC, OpenAPI? a komu to potrzebne? a dlaczego? mamy pelna dowolnosc w projektowaniu swojego api, tylko 'sky is the limit'
- REST==HIV bo wszyscy robimy internalowe api dla spa i mozna walic endpointy jak sie chce, nikt przeciez z tego strzelac nie bedzie
- nikt nigdy powyzszego api, pelnego ulanskiej fantazji, nie bedzie wystawiac

[Czerwony_jak_WIG20]

@MarcinOrlowski: jałowy jest cały ten wątek, spuszczacie się nad tym, jakby to było co najmniej wyznanie wiary, a za 5 lat i tak będzie jakiś nowy standard, a potem znowu coś nowego... nie szkoda wam życia na spory? ( ͡° ͜ʖ ͡°)

[Xirate]

@MarcinOrlowski: Myślę, że ludzie nie ogarniają, że utworzenie połączenia między dwoma urządzeniami i pomyślne przesłanie danych to oddzielne rzeczy i inaczej powinno obsługiwać się błędy w tych dwóch sytuacjach, a te mondzioły chciałyby wszystko na raz jedną rzeczą załatwić, bo tak przecież prościej ¯\_(ツ)_/¯ łączę się w bulu i nadzieji

[EmcePomidor2]

@aka-mikado: xD

[z.....z]

Stare dobre czasy phpowego dzikiego zachodu i freelancerki na studiach. Człowiek pisał straszne gówno, które w sumie nie wiadomo czemu działało i nikogo nie obchodziły jakieś standardy. ( ͡° ͜ʖ ͡°) Pokory dopiero uczyło jak trzeba było poprawiać takie same gówno zrobione przez kogoś innego

[eloar]

@Poldek0000: no właśnie znam i zawsze mnie to irytuje. Robiłem API dla bankowości, dla systemów transakcyjnych, szybkich płatności, dla brokerów, dla dystrybucji spożywczej i maszyn i nigdy nigdzie nie odwalaliśmy takich manian. Klient oczywiście się liczy i dlatego klient dostawał zawsze ładną i kolorową dokumentację, gdzie były podane maksymalne czasy odpowiedzi i inne pierdoły, których potem nikt nie mierzył. W tych samych branżach po drugiej stronie znajdowaliśmy potworki jak opisane tu

[R4vPL]

@DooBeeDooBee graphql jest dodatkowa warstwa transportu, gdzie budujesz query. Tam z resztą też nie wszystko zwraca 200, ale 20x...

[WaveCreator]

Raz się spotkałem z takim rozwiązaniem - dotyczyło ono fasady odpytywanej bezpośrednio przez front o różne enrichmenty itp. - uzasadnienie było takie, że nie chcemy walić błędami w konsoli dla niekrytycznych requestów (a ta usługa obsługiwała wyłącznie niekrytyczne). I w zasadzie tyle. Mnie osobiście ani to ziębi ani grzeje ¯\_(ツ)_/¯

[wrzucambolubie]

@Poldek0000: You give REST a bad name ( ͡° ͜ʖ ͡° )つ──☆*:・ﾟ hehe

[some_ONE]

@aka-mikado: To niezłe #!$%@? juniorka po butkampie, który jak raz przeczyta, że istnieje coś takiego jak REST to teraz wszystko ma mieć RESTa.

- zwracanie 200 przy bledzie jest ok, bo graphql: "task failed successfully"

Nie no, akurat to według mnie nie jest ok, bo wprowadza tylko zamieszanie.

- jakies specyfikacje i wytyczne, RFC, OpenAPI? a komu to potrzebne? a dlaczego? mamy pelna dowolnosc w projektowaniu swojego api, tylko 'sky is

[K.....7]

Śmieszny wątek, polecam przed spaniem na poprawę humoru.
Ja to bym od razu kazał warstwie fizycznej wysyłać 200 OK, nie ważne jakiej, może być gołąb pocztowy, jak nie dotrze do celu to można uznać ze to jednak UDP