@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 znaczenia.
@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.
@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ć.
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
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 na swiat - a jesli
@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? ( ͡°͜ʖ͡°)
@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
@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
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 ¯\_(ツ)_/¯
Ś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
#sct #krakow ludziom którzy nie widzą problemu ani dyskryminacji w strefie czystego transportu i sprowadzają problem do sebka w starym dieslu szkoda cokolwiek tłumaczyć, widać że jest tam za mało komórek pojąć problem który ich nie dotyczy bezpośrednio
źródło: comment_1661241030Q6zeOFVUqPPpeu9NMeA6m0.jpg
Pobierz200 = OK zwiększyłem licznik, inny status = jakieś błędy i mogę sobie wtedy debugować
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 ;-)
Nie wyraziłem opinii, by się mylić. Skierowałem cię tylko do źródeł specyfikacji. Akurat moja opinia nie ma tu znaczenia.
@MarcinOrlowski: mam nadzieję, że nigdy nie spotkam podobnych nie-bootcampowców na swojej biznesowej drodze
- 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 na swiat
- a jesli
Komentarz usunięty przez autora
Nie no, akurat to według mnie nie jest ok, bo wprowadza tylko
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
Komentarz usunięty przez autora