Vraag HTTP GET met verzoek body


Ik ontwikkel een nieuwe RESTful webservice voor onze applicatie.

Wanneer een GET wordt uitgevoerd op bepaalde entiteiten, kunnen klanten de inhoud van de entiteit opvragen. Als ze enkele parameters willen toevoegen (bijvoorbeeld een lijst sorteren), kunnen ze deze parameters toevoegen aan de queryreeks.

Als alternatief wil ik dat mensen deze parameters kunnen specificeren in de verzoekende instantie. HTTP / 1.1 lijkt dit niet expliciet te verbieden. Hierdoor kunnen ze meer informatie opgeven, waardoor het eenvoudiger wordt om complexe XML-verzoeken op te geven.

Mijn vragen:

  • Is dit een goed idee helemaal?
  • Zullen HTTP-clients problemen hebben met het gebruik van verzoekende instanties binnen een GET-verzoek?

http://tools.ietf.org/html/rfc2616


1410
2018-06-10 20:47


oorsprong


antwoorden:


Roy Fielding's opmerking over het opnemen van een instantie met een GET-verzoek.

Ja. Met andere woorden, elk HTTP-verzoekbericht mag bevatten   een berichttekst, en moet dus berichten met dat in gedachten parseren.   Server-semantiek voor GET is echter zo beperkt dat een lichaam,   indien van toepassing, heeft geen semantische betekenis aan het verzoek. De vereisten   bij het ontleden staan ​​los van de vereisten voor de methode-semantiek.

Dus, ja, je kunt een lichaam met GET sturen, en nee, het is nooit nuttig   om dit te doen.

Dit maakt deel uit van het gelaagde ontwerp van HTTP / 1.1 dat zal worden   wis opnieuw als de specificatie is gepartitioneerd (werk in uitvoering).

.... Roy

Ja, u kunt een verzoekschrift verzenden met GET, maar het zou geen enkele betekenis moeten hebben. Als je het betekenis geeft door het te ontleden op de server en veranderend uw antwoord op basis van de inhoud, dan negeer je deze aanbeveling in de HTTP / 1.1-specificatie, sectie 4.3:

[...] als de verzoekmethode      bevat geen gedefinieerde semantiek voor een entiteits-instantie, dan de      bericht lichaam MOET worden genegeerd bij het verwerken van het verzoek.

En de beschrijving van de GET-methode in de HTTP / 1.1-specificatie, paragraaf 9.3:

De GET-methode betekent dat alle informatie wordt opgehaald ([...]) wordt geïdentificeerd door de Request-URI.

waarin staat dat de verzoekende instantie geen deel uitmaakt van de identificatie van de bron in een GET-verzoek, alleen de aanvraag-URI.


1200
2018-06-11 20:27



Terwijl jij kan doe dat, voor zover het niet expliciet wordt uitgesloten door de HTTP-specificatie, zou ik willen voorstellen het simpelweg te vermijden omdat mensen niet verwachten dat dingen op die manier zullen werken. Er zijn veel fasen in een HTTP-aanvraagketen en terwijl ze "overwegend" voldoen aan de HTTP-specificatie, is het enige waar je zeker van bent dat ze zich zullen gedragen zoals traditioneel wordt gebruikt door webbrowsers. (Ik denk aan zaken als transparante proxy's, accelerators, A / V-toolkits, enz.)

Dit is de geest achter de Robuustheid Principe grof gezegd "wees liberaal in wat u accepteert en conservatief in wat u verzendt", u wilt niet zonder reden de grenzen van een specificatie verleggen.

Maar als je een goede reden hebt, ga ervoor.


234
2018-06-10 20:53



U zult waarschijnlijk problemen tegenkomen als u ooit probeert te profiteren van caching. Proxy's zullen niet in de GET-body kijken om te zien of de parameters een impact hebben op de respons.


116
2018-06-10 21:10



Geen van beide restclient noch REST-console steun dit maar krul wel.

De HTTP-specificatie zegt in paragraaf 4.3

Een bericht-instantie MOET NIET in een verzoek worden opgenomen als de specificatie van de verzoekmethode (sectie 5.1.1) het niet toestaat om een ​​entiteit-instantie in verzoeken te verzenden.

Paragraaf 5.1.1 leidt ons door naar sectie 9.x voor de verschillende methoden. Geen van hen verbiedt expliciet de opname van een berichttekst. Echter...

Paragraaf 5.2 zegt

De exacte bron die wordt geïdentificeerd door een internetverzoek, wordt bepaald door zowel het veld Vraag-URI als de host-header te bekijken.

en Paragraaf 9.3 zegt

De GET-methode betekent dat elke informatie wordt opgehaald (in de vorm van een entiteit) wordt geïdentificeerd door de Request-URI.

Die samen suggereren dat wanneer een GET-aanvraag wordt verwerkt, een server dat niet is verplicht om iets anders te onderzoeken dat het veld Request-URI en Host-header bevat.

Samengevat, de HTTP-specificatie belet niet dat je een bericht-body met GET verzendt, maar er is voldoende onduidelijkheid dat het me niet zou verbazen als het niet door alle servers zou worden ondersteund.


60
2018-03-27 10:41



Elasticsearch accepteert GET-verzoeken met een instantie. Het lijkt zelfs alsof dit de voorkeur heeft: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/common-options.html#_request_body_in_query_string

Sommige clientbibliotheken (zoals het Ruby-stuurprogramma) kunnen het cry-commando loggen om in de ontwikkelingsmodus te stdout en het gebruikt deze syntaxis uitgebreid.


36
2017-12-03 11:15



Wat u probeert te bereiken, is al lang gedaan met een veel meer gebruikelijke methode, en een methode die niet afhankelijk is van het gebruik van een payload met GET.

U kunt eenvoudig uw specifieke zoekmediatype samenstellen, of als u meer RUST wilt, gebruik dan iets als OpenSearch en POST het verzoek naar de URI die de server heeft geïnstrueerd, zeg / zoek. De server kan vervolgens het zoekresultaat genereren of de uiteindelijke URI opbouwen en omleiden met behulp van een 303.

Dit heeft het voordeel van het volgen van de traditionele PRG-methode, helpt cachetussenpersonen de resultaten cachen, enz.

Dat gezegd hebbende, zijn URI's sowieso gecodeerd voor iets dat geen ASCII is, en dat geldt ook voor application / x-www-form-urlencoded en multipart / form-data. Ik zou aanraden dit te gebruiken in plaats van nog een ander aangepast json-formaat te maken als het je bedoeling is om ReSTful-scenario's te ondersteunen.


25
2018-06-10 22:47



Welke server negeert het? - fijiaaron 30 augustus '12 om 21:27 uur

Google bijvoorbeeld doet het erger dan het negeren, het zal het beschouwen als een fout!

Probeer het zelf met een simpele netcat:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(de inhoud van 1234 wordt gevolgd door CR-LF, dus dat is een totaal van 6 bytes)

en je krijgt:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

Je krijgt ook 400 Bad Request van Bing, Apple, enz ... die door AkamaiGhost worden bediend.

Dus ik zou niet adviseren om GET-verzoeken te gebruiken bij een instantie van het lichaam.


23
2018-06-29 21:26