pomieszanie GET z POST

Mam zrobić aplikacje, która wywoła pewne serwisy RESTowe i opakuje je w nowe RESTy dla klienta zewnętrznego (UI). Mój jeden Rest serwis, woła jeden Rest serwis z tej odziedziczonej apki. Takie w sumie trochę proxy. API które dostałem to same POSTy. Lista elementów, dociągnięcie elementu po id, to NIE Gety, a Posty i to z dużym payloadem (z 10-15 parametrów).

Co lepsze dla tego webowego klienta:
-opakowanie tych Postów co powinny być Getami, w GETy z duża listą parametrów w querystring,,
-opakowanie tych Postów co powinny być Getami, w kolejne Posty, by ta pokaźną listę parametrów mieć ciągle w payloadzie
-jeszcze inaczej.

Które rozwiązanie najlepsze i dlaczego?

IMO REST to bardziej filozofia (a przynajmniej ja to tak traktuję) i nie trzeba się tego jakoś kurczowo trzymać vide PUT i PATCH i nieustająca wojenka, co, kiedy i dlaczego. Użycie POST zamiast GET nie jest przestępstwem IMO, tym bardziej, że z tego co wiem QPs mają jakąś ustaloną z góry długość i jak np. w zapytaniu masz masę IDeków, to lepiej to w body wysłać.

Reasumując, tylko z powodu ogromnej ilości parametrów wysłałbym to POSTEM i się nie przejmował :)

GraphQL wszystko napierdziela POST i wtedy jest ok, ale jak REST to wtedy jest źle.

Parametry w GET są OK, ale nie jeśli jest ich dużo albo są tam przekazywane jakies złożone modele typu listy bez umiaru, bo niestety (albo i stety) długość URL jest ograniczona.

• GET
  • cachowalność po URI na różnych warstwach
  • bookmarkowalność
  • otwieranie zasobów w osobnych zakładkach
  • twój system może być badany/crawlowany/monitorowany przez mechanizm, który działa na innej warstwie abstrakcji
  • masz historię zapytań w logach http
  • trzymasz się konwencji, więc unikasz potrzeby dokumentowania, że GET nie ma skutków ubocznych, itp
  • mniej drażnienia restowych dewotów
• POST
  • unikasz technicznych ograniczeń na długość URL i problemów z kodowaniem znaków, tablic i nulli
  • nie masz wrażliwych parametrów w logach http
  • trudniejszy atak typu csrf
  • masz możliwość stworzenia prawdziwego proxy (takie samo api)

Z tego, co opisałeś, nie wynika, żebyś potrzebował pełnej filozofii resta, więc skłaniałbym się do opcji z POSTem.

Nie podałeś, czego potrzebuje to UI, a to może być wskazówka do designu API. Niektórzy nawet twierdzą, że od tego trzeba zaczynać.

System ma działać a nie sztywno trzymać się konwencji. Jak zamapujesz RESTem funkcjonalność typu OCR:
String recognize(Image img)?
Niby jest to funkcja pure, bez żadnych efektów ubocznych, ale życzę powodzenia w przesyłaniu obrazku jako parametru w URL.

Nie ma nic złego w eksploatacji protokołu HTTP na własne potrzeby, i stworzenia web API skrojonego pod własne potrzeby. Tylko po co to nazywać RESTEM, skoro to RESTEM nie jest?

A kto powiedział, że odpytywanie POSTem jest niezgodne z RESTem?

somekind napisał(a):

A kto powiedział, że odpytywanie POSTem jest niezgodne z RESTem?

A to mógłbyś się kłócić godzinami z moim nawiedzonym architektem z byłej firmy, fanatykiem odata :)

Plus raz mnie odrzucili na rozmowie, bo się jakiś architekt pytał jakiego verba bym użył do wyszukiwarki z pierdyliardem pól do filtrowania.
Jak wspomniałem o możliwości przekroczenia długości maks url na niektórych serwerach i próbie użycia POSTa, to zrobił minę kota srajacego na pustyni :D

urke napisał(a):

A to mógłbyś się kłócić godzinami z moim nawiedzonym architektem z byłej firmy, fanatykiem odata :)

Nie kłóciłbym się godzinami, poprosiłbym o wskazanie takiego twierdzenia w pracy źródłowej albo oddalenie się pospieszne w sobie tylko znanym kierunku.

Plus raz mnie odrzucili na rozmowie, bo się jakiś architekt pytał jakiego verba bym użył do wyszukiwarki z pierdyliardem pól do filtrowania.
Jak wspomniałem o możliwości przekroczenia długości maks url na niektórych serwerach i próbie użycia POSTa, to zrobił minę kota srajacego na pustyni :D

Mnie kiedyś odrzucili, bo powiedziałem, ze w kontrolerach nie umieszcza się logiki biznesowej.
Nic nie poradzisz na wychowanków marnej jakości tutoriali.

somekind napisał(a):

Nie kłóciłbym się godzinami, poprosiłbym o wskazanie takiego twierdzenia w pracy źródłowej albo oddalenie się pospieszne w sobie tylko znanym kierunku.

W przypadku REST może być ciężko o prace źródłową, albo chociaż wspólny pogląd czym to właściwie jest. Wydaje mi się, że to częsty w IT przypadek, kiedy ktoś rzuci jakąś prawdę w kontekście konkretnego przypadku, a tłum podchwytuje i zaczyna toczyć świętą wojnę o to czy coś co przyjmuje żądania POST'em to jeszcze REST, czy już herezja.

Mnie kiedyś odrzucili, bo powiedziałem, ze w kontrolerach nie umieszcza się logiki biznesowej.

Mogło być gorzej, mogli cię przyjąć i wtedy takie dyskusje miałbyś codziennie.

W przypadku REST może być ciężko o prace źródłową, albo chociaż wspólny pogląd czym to właściwie jest. Wydaje mi się, że to częsty w IT przypadek, kiedy ktoś rzuci jakąś prawdę w kontekście konkretnego przypadku, a tłum podchwytuje i zaczyna toczyć świętą wojnę o to czy coś co przyjmuje żądania POST'em to jeszcze REST, czy już herezja.

@piotrpo: wydaje mi się, że jest całkowicie odmiennie. Do mainstreamu trafiają hasła/pojęcia, które nie są dobrze zdefiniowane i w wielu aspektach trzeba się domyślać/szukać prawdy. Tak jest z Restem (jak mapować rzeczy, które nie są zasobami jako zasób?), TDD (serio mam pisać testy do każdej klasy i mockować wszystko tak jak pokazali na szkoleniu z TDD?), OOP (czym w zasadzie jest OOP?), Hex architecture (na ch**j ktoś wrzucił te heksy?) i pewnie dałoby się znaleźć więcej przykładów. Jak coś jest dobrze zdefiniowane to nie wzbudza wyobraźni, nie potrzeba speakerów na konferencjach, nie trzeba pisać książek i tworzyć tematów na forum takich jak ten

@slsy: Nie wiem czy to ma znaczenie, w którą stronę są dopisywane treści i znaczenia. Takie relacyjne bazy danych są doskonale zdefiniowane, przebadane, praktycznie każdy programista ma o nich jakieś tam pojęcie, a jak przyjdzie do omówienia najprostszych definicji do zima, zaczynając od wydawałoby się podstawowego pojęcia "relacja". To nawet nie jest źle, dopóki jakoś tam przekłada się na sensowną praktykę. Gorzej, gdy te nie do końca jasne, albo nie do końca zrozumiane pojęcia stają się celem samym w sobie i trzeba coś tam zaimplementować koniecznie używając jakiejś "najlepszej" techniki. To, że jest to dobre rozwiązanie innego problemu nie ma znaczenia, przecież wiadomo, ze CQRS + ES będzie najlepszym rozwiązaniem zawsze i wszędzie. A ferrari to lepszy samochód niż passat, nawet jak trzeba przywieźć meble z ikea.
Przypomina mi się dyskusja w tym dziale o tym jak złe są mikroserwisy, w której koniec końców wyszło, że ani rozwiązanie nie było specjalnie pod taką architekturę, ani ostateczna architektura nie miała za wiele wspólnego z mikroserwisami. A przecież to pojęcie też nie jest mega skomplikowane, tylko jednak trochę bardziej złożone, niż "będziemy mieli więcej usług niż jedna".