Frage HTTP GET mit dem Anfragetext


Ich entwickle einen neuen RESTful Webservice für unsere Anwendung.

Wenn ein GET für bestimmte Entitäten ausgeführt wird, können Clients den Inhalt der Entität anfordern. Wenn sie einige Parameter hinzufügen möchten (z. B. das Sortieren einer Liste), können sie diese Parameter in der Abfragezeichenfolge hinzufügen.

Alternativ möchte ich, dass die Benutzer diese Parameter im Anfragetext angeben können. HTTP / 1.1 scheint das nicht explizit zu verbieten. Dadurch können sie mehr Informationen angeben, wodurch die Angabe komplexer XML-Anforderungen erleichtert wird.

Meine Fragen:

  • Ist das überhaupt eine gute Idee?
  • Haben HTTP-Clients Probleme mit der Verwendung von Anforderungsstellen innerhalb einer GET-Anfrage?

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


1410
2018-06-10 20:47


Ursprung


Antworten:


Roy Fieldings Kommentar zum Einfügen eines Body mit einer GET-Anfrage.

Ja. Mit anderen Worten, jede HTTP-Anforderungsnachricht darf enthalten   ein Nachrichtentext und muss daher Nachrichten mit diesem Gedanken analysieren.   Serversemantik für GET ist jedoch so eingeschränkt, dass ein Körper,   falls vorhanden, hat keine semantische Bedeutung für die Anfrage. Die Anforderungen   beim Parsen sind getrennt von den Anforderungen an Methodensemantik.

Also, ja, Sie können einen Körper mit GET senden, und nein, es ist nie nützlich   um es zu tun.

Dies ist Teil des geschichteten Designs von HTTP / 1.1   wieder löschen, sobald die Spezifikation partitioniert ist (Arbeit in Arbeit).

.... Roy

Ja, Sie können eine Anfrage mit GET senden, aber es sollte keine Bedeutung haben. Wenn Sie es durch Parsing auf dem Server und Ändern Sie Ihre Antwort basierend auf ihren Inhaltendann ignorierst du diese Empfehlung in die HTTP / 1.1-Spezifikation, Abschnitt 4.3:

[...] wenn die Anfrage Methode      enthält keine definierte Semantik für einen Entity-Body, dann die      Nachrichtentext SOLLTE Bei der Bearbeitung der Anfrage ignoriert werden.

Und die Beschreibung der GET-Methode in die HTTP / 1.1 Spezifikation, Abschnitt 9.3:

Die GET-Methode bedeutet, dass alle Informationen abgerufen werden, die [...] durch den Request-URI identifiziert werden.

die besagt, dass der Anfrage-Körper nicht Teil der Identifikation der Ressource in einer GET-Anfrage ist, nur die Anfrage-URI.


1200
2018-06-11 20:27



Während du kann tun Sie das, sofern es nicht explizit durch die HTTP-Spezifikation ausgeschlossen ist, würde ich vorschlagen, es zu vermeiden, weil die Leute nicht erwarten, dass die Dinge so funktionieren. Es gibt viele Phasen in einer HTTP-Anforderungskette, und obwohl sie "größtenteils" mit der HTTP-Spezifikation übereinstimmen, ist das Einzige, was Sie sicherstellen können, dass sie sich so verhalten, wie sie von Webbrowsern traditionell verwendet werden. (Ich denke an Dinge wie transparente Proxies, Beschleuniger, A / V Toolkits, etc.)

Das ist der Geist hinter dem Robustheitsprinzip grob "sei liberal in dem, was du akzeptierst, und konservativ in dem, was du sendest", du willst die Grenzen einer Spezifikation nicht ohne guten Grund verschieben.

Wenn Sie jedoch einen guten Grund haben, gehen Sie darauf ein.


234
2018-06-10 20:53



Sie werden wahrscheinlich auf Probleme stoßen, wenn Sie jemals versuchen, das Caching zu nutzen. Proxies werden nicht in den GET-Body schauen, um zu sehen, ob die Parameter einen Einfluss auf die Antwort haben.


116
2018-06-10 21:10



Weder Restclient Noch REST-Konsole Unterstützen Sie dies, aber Curl tut.

Das HTTP-Spezifikation sagt in Abschnitt 4.3

Ein Nachrichtentext DARF NICHT in eine Anfrage aufgenommen werden, wenn die Angabe der Anfrage-Methode (Abschnitt 5.1.1) das Senden einer Entity-Body in Anfragen nicht erlaubt.

Abschnitt 5.1.1 leitet uns zu Abschnitt 9.x für die verschiedenen Methoden um. Keine von ihnen verbietet explizit die Aufnahme eines Nachrichtentextes. Jedoch...

Abschnitt 5.2 sagt

Die genaue Ressource, die durch eine Internetanforderung identifiziert wird, wird durch Überprüfen sowohl des Anfrage-URI- als auch des Host-Header-Felds bestimmt.

und Abschnitt 9.3 sagt

Die GET-Methode bedeutet, dass alle Informationen (in Form einer Entität) durch den Request-URI identifiziert werden.

Was zusammen ergibt, dass bei der Verarbeitung einer GET-Anfrage kein Server dies tut erforderlich um alles andere zu untersuchen, das das Headerfeld Request-URI und Host ist.

Zusammengefasst verhindert die HTTP-Spezifikation nicht, dass Sie einen Nachrichtentext mit GET senden, aber es gibt genügend Zweideutigkeit, dass es mich nicht überraschen würde, wenn es nicht von allen Servern unterstützt würde.


60
2018-03-27 10:41



Elasticsearch akzeptiert GET-Anfragen mit einem Body. Es scheint sogar, dass dies der bevorzugte Weg ist: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/common-options.html#_request_body_in_query_string

Einige Client-Bibliotheken (wie der Ruby-Treiber) können den Befehl "cry" im Entwicklungsmodus auf stdout protokollieren und verwenden diese Syntax ausgiebig.


36
2017-12-03 11:15



Was Sie erreichen wollen, wurde lange Zeit mit einer viel gebräuchlicheren Methode gemacht, die nicht darauf angewiesen ist, eine Nutzlast mit GET zu verwenden.

Sie können einfach Ihren spezifischen Medientyp für die Suche erstellen, oder, wenn Sie eher RESTful sein möchten, verwenden Sie so etwas wie OpenSearch und POST die Anfrage an den URI, den der Server angewiesen hat, sagen / suchen. Der Server kann dann das Suchergebnis erzeugen oder den endgültigen URI erstellen und mit einer 303 weiterleiten.

Dies hat den Vorteil, der traditionellen PRG-Methode zu folgen, hilft Zwischenspeicher-Vermittlern, die Ergebnisse zu cachen usw.

Das heißt, URIs werden sowieso für alles codiert, was nicht ASCII ist, und so sind auch application / x-www-form-urlencoded und multipart / form-data. Ich würde empfehlen, dies zu verwenden, anstatt ein weiteres benutzerdefiniertes JSON-Format zu erstellen, wenn Sie ReSTful-Szenarien unterstützen möchten.


25
2018-06-10 22:47



Welcher Server wird es ignorieren? - Fijiaaron 30. August 12 um 21:27 Uhr

Google zum Beispiel macht es schlimmer, als es zu ignorieren, es wird es als ein betrachten Error!

Probieren Sie es mit einem einfachen Netcat aus:

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

1234

(auf den 1234-Inhalt folgt CR-LF, also insgesamt 6 Byte)

und du wirst bekommen:

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.

Sie erhalten auch 400 Bad Request von Bing, Apple, etc ..., die von AkamaiGhost bedient werden.

Daher würde ich nicht empfehlen, GET-Anfragen mit einer Körper-Entität zu verwenden.


23
2018-06-29 21:26



Sie können entweder ein GET mit einem Körper senden oder einen POST senden und RESTish Religiosität aufgeben (es ist nicht so schlimm, vor 5 Jahren gab es nur ein Mitglied dieses Glaubens - seine Kommentare oben verlinkt).

Es sind keine großen Entscheidungen, aber das Senden eines GET-Body kann Probleme für einige Clients - und einige Server - verhindern.

Ein POST kann mit einigen RESTish-Frameworks Probleme bereiten.

Julian Reschke schlug oben einen nicht standardmäßigen HTTP-Header wie "SEARCH" vor, was eine elegante Lösung sein könnte, außer dass es noch weniger wahrscheinlich unterstützt wird.

Es könnte am produktivsten sein, Clients aufzulisten, die das jeweils oben genannte tun können und können.

Clients, die kein GET mit Körper senden können (den ich kenne):

  • XmlHTTPRequest Fiddler

Clients, die ein GET mit body senden können:

  • die meisten Browser

Server und Bibliotheken, die einen Körper von GET abrufen können:

  • Apache
  • PHP

Server (und Proxies), die einen Körper von GET entfernen:

  • ?

21
2017-08-30 21:41