Die neue HTTP-Methode QUERY

Erklärung der neu in RFC 10008 definierten HTTP-Methode QUERY

Bei bestehenden RESTful APIs hatten sowohl GET als auch POST Grenzen, wenn es darum ging, komplexe Suchanfragen zu verarbeiten. Nach langer Diskussion wurde die Methode QUERY standardisiert, um dieses Problem zu lösen.

Grenzen von GET

• Wenn komplexe Filter oder relationale Abfragen als URL-Parameter gesendet werden, wird die URL übermäßig lang und kann an Zeichenlimits von Browsern oder Servern stoßen.
• Nicht-ASCII-Zeichen oder Sonderzeichen müssen codiert werden, wodurch die Größe der Anfrage steigt.
• Darstellungsformen für Arrays oder verschachtelte Strukturen sind nicht standardisiert (z. B. roles[]=admin vs. roles=admin).
• Server/Middleware protokollieren URL-Parameter in Logs, was beim Übertragen sensibler Daten problematisch ist.
• Einen Request Body mit GET zu senden, ist in der Spezifikation zwar nicht ausdrücklich verboten, wird aber von Proxys, Firewalls und Browsern unterschiedlich behandelt und ist daher praktisch nicht nutzbar.

Probleme beim Ausweichen auf POST

• Ein Request Body kann zwar gesendet werden, doch POST ist als nicht idempotent (non-idempotent) definiert, sodass automatische Wiederholungen bei Fehlern nicht sicher sind.
• Proxys oder Middleware können nicht erkennen, dass es sich um eine reine Leseoperation handelt; Optimierungen wie automatisches Caching sind daher nicht möglich.
• POST, das semantisch für das Erstellen/Verarbeiten von Ressourcen gedacht ist, für Suchen zu verwenden, passt nicht zu RESTful-Designprinzipien.

QUERY-Methode

• Eine neue HTTP-Methode, die wie GET sicher (safe) und idempotent (idempotent) ist, aber einen Request Body enthalten kann.
• Caching ist möglich, allerdings muss bei der Implementierung der Request Body in den Cache Key einbezogen werden, wodurch die Caching-Implementierung komplexer ist als bei GET.
• Kurz gesagt: Das Hauptziel ist, „POST bei reinen Leseanfragen zu ersetzen“.

Hinweise

• Die Unterstützung für QUERY in Clients, Proxys und Servern ist noch begrenzt; bis zur vollständigen Unterstützung kann es dauern.
• Wenn einfache GET-Query-Parameter ausreichen, besteht kein Grund zur Umstellung.
• Wenn das Teilen von URLs oder Bookmarks für gefilterte Daten erforderlich ist, bleibt GET weiterhin geeignet.

[jongyeol]

Das Senden eines Request-Bodys mit GET ist laut Spezifikation nicht ausdrücklich verboten, aber da Proxys/Firewalls/Browser es jeweils unterschiedlich verarbeiten, ist es in der Praxis nicht nutzbar

Äh ... hat man dabei nicht bedacht, dass die QUERY-Methode je nach Proxy/Firewall/Browser auch in den nächsten zehn Jahren womöglich noch nicht unterstützt wird? Oder war das vielleicht mit sehr langfristigem Blick gedacht?

[tesha001]

Ich glaube, es ist Letzteres.

[click]

Ich erinnere mich, dass es bei der Service-API eines bestimmten Unternehmens ein Problem gab: Obwohl sie POST empfing, funktionierte sie nicht, wenn dieselben URL-Parameter nicht ebenfalls mitgegeben wurden.
In Korea gibt es noch ziemlich oft Reaktionen wie »Was soll denn PUT oder DELETE überhaupt sein?« — ich weiß nicht, wie lange es dauern wird, bis sich sogar QUERY etabliert.

[sea715]

??? : Macht es nicht RESTful, sondern vereinheitlicht einfach alles mit POST

[savvykang]

???: POST ist gut für die Sicherheit

[ultimategamer]

Das RFC-Dokument ist https://datatracker.ietf.org/doc/rfc10008/.
GET hat zwar den Nachteil, dass die URL länger wird, aber ich finde, es hat auch den Vorteil, dass man die URL selbst direkt teilen kann, etwa wenn man die Ergebnisse bestimmter Suchfilter in ElasticSearch teilen möchte.

Da GET-Anfragen oft implizit unter der Annahme verwendet werden, dass sie in die Adresszeile des Browsers eingegeben werden, dürfte es wohl nicht nur technische Unterstützung brauchen, sondern auch viel Zeit, bis sich das etabliert.