Wpis z mikrobloga

Hej mireczki, mógłby mi ktoś wytłumaczyć parę kwestii? Dlaczego HTTP Get nie powinien mieć ciała, a może przesyłać dane np. w URLce (stringi typu id, email itp.)? W jaki sposób rozwiązać problem kiedy chcę pobierać z API np. Userów bazując na mniej czy bardziej złożonych kryteriach, które najprościej byłoby wrzucić do jakiegoś innego obiektu (np. SearchCriteria) i posłać do api jako body? Ale jednocześnie robiąc to wszystko po Bożemu ze specyfikacją HTTP/REST? Wysyłanie tego w jakiejś ogromnej URLce nie wydaje się być najlepszym pomysłem.
#naukaprogramowania #prograwanie #programista15k #angular #rest #http #api
  • 9
@FaenTaDeg:

Be careful!!! GET method must be IDEMPOTENT, and must be "cacheable". If you send information in the body How can the system cache your request? HTTP allows caching GET request using only the URL, not the request body. For instance, this two requests: example.com { test:"some" } example.com { anotherTest:"some2" } are considered the same by the cache system: Both of them have exactly the same URL

https://stackoverflow.com/questions/5020704/how-to-design-restful-search-filtering#comment45639456_5020704

chyba chodzi
@FaenTaDeg: Chodzi o standardową implementację, w której przyjęło się że serwer obsługujący metodę GET nie przetwarza payloadu (chociaż mógłbyś go wysłać). Standardem przy większych zapytaniach jest używanie metody POST z payloadem w którym definiujesz SearchCriteria. To nie jest tak że każdy "POST" musi coś tworzyć; nie warto się trzymać sztywno tej reguły (można to zdefiniować na poziomie endpoint '/Search'). Poza tym jak świat długi i szerogi, znalezienie dobrego REST service gdzie
możesz wysłać searchCriteria w GET jako url query np. ...&search=name:dupa,age>15,... tylko później w backendzie musisz to przeparsować np. regexem i zbudować na tej podstawie obiekt criteria, znaki :, ==, >, <> są operatorami np. like, equal, grather then, not equal

wg. mnie sposób lepszy niż request POST i searchCriteria w body