POST HTTP z parametrami zapytań URL-dobry pomysł czy nie?

Każdy ma rację: trzymaj się postu dla nie idempotentnych żądań.

A co z używaniem zarówno ciągu zapytania URI, jak i treści żądania? Dobrze jest to poprawne HTTP( patrz uwaga 1), więc dlaczego nie!

Jest to również całkowicie logiczne: adresy URL, w tym ich część łańcucha zapytań, są przeznaczone do lokalizowania zasobów. Natomiast metoda HTTP (POST - i jej opcjonalna treść żądania) służy do określania akcji, czyli co zrobić z zasobami. To powinny być problemy ortogonalne. (Ale oni nie są pięknie ortogonalnymi problemami dla specjalnego przypadku ContentType=application / x-www-form-urlencoded, patrz uwaga 2 poniżej.)

Uwaga 1: specyfikacja HTTP (1.1) nie stwierdza, że parametry zapytania i zawartość wzajemnie się wykluczają dla serwera HTTP, który akceptuje żądania POST lub PUT. Więc każdy serwer może zaakceptować oba. Tzn. jeśli piszesz serwer to nic nie stoi na przeszkodzie, żebyś zaakceptował oba (może poza nieelastycznym frameworkiem). Ogólnie serwer może interpretować zapytania ciągów zgodnie z dowolnymi regułami, jakie chce. Może nawet interpretować je za pomocą logiki warunkowej, która odnosi się do innych nagłówków, takich jak Content-Type, co prowadzi do Uwagi 2:

Uwaga 2: Jeśli przeglądarka internetowa jest podstawowym sposobem, w jaki ludzie uzyskują dostęp do Twojej aplikacji internetowej, a application/x-www-form-urlencoded jest typem treści, który publikują, to powinieneś przestrzegać zasad dla tego typu treści. A zasady aplikacji / x-www-form-urlencoded to znacznie bardziej szczegółowe( i szczerze mówiąc, niezwykłe): w tym przypadku musisz zinterpretować URI jako zestaw parametrów, a nie lokalizację zasobów. [Jest to ten sam punkt użyteczności Powerlord podniesiony; że może być trudno używać formularzy internetowych do publikowania treści na serwerze. Wyjaśniłem to trochę inaczej.]

Uwaga 3: do czego pierwotnie służą łańcuchy zapytań? RFC 3986 definiuje ciągi zapytań HTTP jako część URI, która działa jako niehierarchiczny sposób lokalizowania zasobu.

W przypadku czytelników zadając to pytanie pragniemy zapytać, co to jest dobra architektura RESTful: wzór architektury RESTful nie wymaga, aby Schematy URI działały w określony sposób. Architektura RESTful dotyczy innych właściwości systemu, takich jak buforowalność zasobów, projektowanie samych zasobów (ich zachowanie, możliwości i reprezentacje) oraz czy idempotencja jest spełniona. Innymi słowy, osiągnięcie projektu, który jest wysoce kompatybilny z protokołem HTTP i jego zestawem HTTP czasowniki metodyczne. :- ) (Innymi słowy, Architektura RESTful nie jest zbyt intuicyjna z tym, jak znajdują się zasoby .)

Ostatnia uwaga: czasami parametry zapytań są używane do jeszcze innych rzeczy, które nie są ani lokalizowaniem zasobów, ani kodowaniem treści. Czy kiedykolwiek widziałeś parametr zapytania, taki jak "PUT = true" lub "POST = true"? Są to obejścia dla przeglądarek, które nie pozwalają na używanie metod PUT I POST. Chociaż takie parametry są postrzegane jako część ciągu zapytania URL( na drucie), argumentuję że nie są one częścią zapytania URL w duchu .

Chcesz powodów? Oto jeden:

Formularz internetowy nie może być używany do wysyłania żądania do strony, która używa mieszanki GET I POST. Jeśli ustawisz metodę formularza NA GET, wszystkie parametry znajdują się w łańcuchu zapytania. Jeśli ustawisz metodę formularza NA POST, wszystkie parametry znajdują się w treści żądania.

Source: HTML 4.01 standard, section 17.13 Form Submission

Z punktu widzenia programistycznego, dla klienta jest to pakowanie parametrów i dołączanie ich do adresu url i prowadzenie POST vs. GET. Po stronie serwera, ocenia parametry przychodzące z querystring zamiast wysyłanych bajtów. W zasadzie to pranie.

Zalety / wady mogą wynikać z tego, jak konkretne platformy klienckie współpracują z funkcjami POST I GET w stosie sieciowym, a także jak serwer WWW radzi sobie z tymi żądaniami. W zależności od wdrożenia, jedno podejście może być bardziej efektywne niż drugie. Wiedząc, że to pokieruje twoją decyzją.

Niemniej jednak, z punktu widzenia programisty, wolę pozwolić albo POST ze wszystkimi parametrami w ciele, lub GET ze wszystkimi paramami w adresie url, i jawnie ignorując parametry url z dowolnym żądaniem POST. Pozwala uniknąć nieporozumień.

Myślę, że nadal może być dość spokojny, aby mieć argumenty zapytań, które identyfikują zasób na adresie URL, utrzymując ładunek treści ograniczony do ciała posta. Wydaje się to oddzielać rozważania "co wysyłam?"versus" do kogo to wysyłam?".

Obóz REST ma pewne zasady przewodnie, których możemy użyć do standaryzacji sposobu, w jaki używamy czasowników HTTP. Jest to pomocne podczas budowania RESTful API tak, jak to robisz.

W skrócie: GET powinien być tylko odczytywany tzn. nie ma wpływu na stan serwera. POST służy do tworzenia zasobów na serwerze. PUT służy do aktualizacji lub tworzenia zasobu. DELETE służy do usuwania zasobu.

Innymi słowy, jeśli twoje działanie API zmieni stan serwera, REST zaleca nam użycie POST/PUT / DELETE, ale nie GET.

Agenci użytkowników zazwyczaj rozumieją, że robienie wielu postów jest złe i ostrzegają przed tym, ponieważ intencją postu jest zmiana stanu serwera (np. zapłać za towar przy kasie), a prawdopodobnie nie chcesz tego robić dwa razy!

Porównaj z GETEM, który możesz zrobić często, jak chcesz(idempotent).

Zgadzam się - prawdopodobnie bezpieczniej jest użyć żądania GET, jeśli po prostu przekazujesz dane w adresie URL, a nie w ciele. Zobacz to podobne pytanie , aby uzyskać dodatkowe widoki na całą koncepcję POST+GET.