- Eine neue HTTP-Methode namens
QUERY wird vorgeschlagen
- Eine Request-Methode, die Inhalte beim Request übertragen kann und dabei sicher sowie idempotent ist
- Diese Methode kann verwendet werden, wenn die im Request zu übertragenden Daten zu groß sind, um in eine URI codiert zu werden
- Wenn Query-Parameter mehrere KB groß sind, setzen viele Implementierungen Grenzen
- Oft ist diese Grenze vor dem Request nicht im Voraus bekannt, und da codiert werden muss, ist das ineffizient
- Deshalb verwenden viele Implementierungen
POST statt GET, um Queries auszuführen
- Ohne konkretes Wissen über den Server lässt sich jedoch nicht erkennen, ob dies sicher und idempotent ist, wodurch ähnliche grundlegende Einschränkungen wie bei
GET bestehen
- Die Methode
QUERY bietet eine Lösung, um die Lücke zwischen der Verwendung von GET und POST zu schließen
- Wie bei
POST werden Eingaben für Query-Operationen im Inhalt des Requests und nicht als Teil der Request-URI übermittelt
- Anders als bei
POST ist diese Methode jedoch ausdrücklich sicher und idempotent, sodass Funktionen wie Caching und automatische Wiederholungen möglich sind
Request
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv
select surname, givenname, email limit 10
Response
HTTP/1.1 200 OK
Content-Type: text/csv
Content-Location: /contacts/responses/42
Location: /contacts/queries/17
surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
7 Kommentare
Ich verstehe nicht, warum man das dem Protokoll hinzufügen muss.
Gibt es wirklich so viele Szenarien, in denen Query-Parameter mehrere KB überschreiten?
https://www.baeldung.com/cs/http-get-with-body
Es wirkt so, als würde man wegen der HTTP-Spezifikation, die den Lesern Raum für eigene Interpretationen lässt und sich zudem inkonsistent verändert hat, gleich versuchen, eine ganz neue Methode zu schaffen.
GET mit Request-Body
Einige Client-Bibliotheken bieten beim Senden von GET-Anfragen gar keine Möglichkeit, einen Request-Body mitzusenden; dafür könnte das eine Alternative sein.
Aus Sicht der Bibliotheksimplementierung ist das eher ein Vorschlag für eine Standardänderung, den man noch weniger braucht, oder nicht?
Laut Standardspezifikation darf GET keinen Request-Body haben, aber die Bibliothek übergibt willkürlich einen Request-Body ...
Wenn das so ist, wäre es dann nicht genauso gut möglich, einfach auf Bibliotheksebene eine Custom-Methode zu implementieren?
Es ist zwar schwer, die Notwendigkeit komplett zu verneinen, aber im Vergleich zu PUT, PATCH und DELETE, die mit dem Übergang von HTTP 1.0 zu 1.1 entstanden sind, scheint mir das weniger überzeugend.
https://www.rfc-editor.org/rfc/rfc9110.html#name-method-definitions
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET
https://stackoverflow.com/questions/978061/http-get-with-request-body
https://elastic.co/guide/en/…
In der Standard-Spezifikation wird beim GET-Methodenteil der Body nicht ausdrücklich beschrieben, aber es wurde nie gesagt, dass man keinen verwenden darf.
Da es Server-Frameworks gibt, die einen Body bei der GET-Methode nicht verarbeiten, empfiehlt MDN, bei der GET-Methode keinen Body zu verwenden.
Elasticsearch unterstützt einen Body bei der GET-Methode.
Ich denke, es braucht noch mehr Überlegung, ob die Spezifikation wirklich wegen der Implementierung einer Bibliothek geändert werden sollte.