HTTP QUERY: die Methode, die zwischen GET und POST fehlte

Nach mehr als fünfzehn Jahren architektonischer Kompromisse unternimmt die IETF nun endlich einen formellen Schritt, um eine der historischen Lücken von HTTP zu schließen: die sichere und effiziente Verarbeitung komplexer Suchanfragen.

Mit der Einführung der neuen HTTP-QUERY-Methode müssen komplexe Anfragen und Filter nicht mehr in die URL gepackt oder über eine nicht sichere Methode wie POST übertragen werden.

HTTP QUERY, eine neue Methode für die REST-Architektur

Die HTTP-QUERY-Methode ist der erste von der IETF verabschiedete Standard seit PATCH, das bereits 2010 eingeführt wurde. Obwohl sie noch weit von einer flächendeckenden Implementierung entfernt ist, verspricht die QUERY-Methode, eines der ältesten Dilemmata der REST-Architektur zu lösen: Wie lassen sich komplexe Suchanfragen oder Filter senden, ohne gegen die Regeln der HTTP-Standards zu verstoßen?

Bis heute mussten erweiterte Suchanfragen mit Kompromissen umgesetzt werden: Weder GET noch POST sind hierfür eine ideale Lösung.

Die GET-Methode sieht vor, dass Daten über Parameter in der URL übertragen werden (die zudem Längenbeschränkungen unterliegt). Werden Suchparameter jedoch in die URL eingefügt, besteht das Risiko, dass sensible Daten in den Server-Logs offengelegt werden: Wird beispielsweise nach einem bestimmten Vor- und Nachnamen gefiltert, wird dieser in den Logs sichtbar. Die Notwendigkeit, die URL zu verwenden, macht es außerdem unmöglich, komplexe Abfragen wie SQL-Abfragen oder Suchen mit erweiterten Filtern auszuführen.

POST hingegen löst die Platzprobleme, indem die Abfrage im Body übertragen wird, ist aber keine sichere (safe) Methode. POST ist dafür vorgesehen, Daten zu erstellen oder zu ändern, also Daten auf dem Server zu verändern. Daher gilt POST als nicht idempotent: Das mehrfache Senden derselben Anfrage mit POST führt nicht immer zum gleichen Ergebnis (wie es beispielsweise bei GET oder PUT der Fall ist).

Die Eigenschaften der QUERY-Methode

Die neue HTTP-QUERY-Methode löst dieses Problem, indem sie zwei grundlegende Eigenschaften miteinander verbindet: Erstens überträgt sie die Parameter im Body der Anfrage, ohne sie wie bei POST in der URL offenzulegen. Zweitens handelt es sich um eine idempotente und cachefähige Methode wie bei GET.

Zusammengefasst gilt für die QUERY-Methode:

• Sie überträgt Daten im Body: Sie kann daher JSON, GraphQL, eine SQL-ähnliche Syntax oder komplexe Filter enthalten (ohne die Platzbeschränkungen von Query-Strings) und gleichzeitig eine saubere URL beibehalten;
• Sie ist safe: Sie garantiert dem Server und den CDNs, dass es sich um eine reine Leseoperation handelt und der Zustand der Ressourcen nicht verändert wird;
• Sie ist idempotent: Dieselbe Anfrage liefert dasselbe Ergebnis und ermöglicht es Clients, bei einem Netzwerkfehler automatisch einen erneuten Versuch durchzuführen;
• Sie ist cachefähig: Proxies, CDNs und Browser können die Antwort speichern, indem sie einen Cache-Schlüssel auf Grundlage der Kombination aus URL und Body erstellen.

QUERY, das in der RFC 10008 beschrieben wird, die von der IETF im Juni 2026 veröffentlicht wurde, löst somit eine Inkonsistenz, mit der Entwickler seit Jahren konfrontiert sind: Die Methode verbindet die Sicherheit und Idempotenz von GET mit der strukturellen Möglichkeit, ein sehr detailliertes Payload im Body der Anfrage zu übertragen, wie es bei POST der Fall ist.

Der Content-Type bei der QUERY-Methode

Gemäß den in der RFC 10008 festgelegten Spezifikationen ist bei einer QUERY-Anfrage mit einem Body auch der Content-Type zwingend erforderlich. Der Body kann völlig unterschiedliche Formate enthalten, aber der Server und die Netzwerkkomponenten (wie Proxies und CDNs) müssen genau wissen, wie er interpretiert werden soll, bevor er verarbeitet oder im Cache gespeichert wird.

Der neue Standard führt zu diesem Zweck einen „Accept-Query“-Response-Header ein, der dem Client mitteilt, welche Abfrageformate der Server im Body einer Anfrage akzeptieren und verarbeiten kann.

Die RFC 10008 führt außerdem die entsprechenden Fehlermeldungen ein:

• 400 Bad Request: wenn der Media Type fehlt oder der Body syntaktisch fehlerhaft ist;
• 415 Unsupported Media Type: wenn das Format vom Endpoint nicht unterstützt wird;
• 406 Not Acceptable: wenn das in „Accept“ angeforderte Format nicht bereitgestellt werden kann;
• 422 Unprocessable Content: wenn die Abfrage syntaktisch gültig ist (z. B. korrektes JSON), die Daten jedoch gegen die Geschäftsregeln der Anwendung verstoßen und für den Server daher logisch keinen Sinn ergeben.

HTTP QUERY: der Weg zur Einführung der neuen Methode

Mit einer flächendeckenden Einführung der QUERY-Methode wird voraussichtlich zwischen 2027 und 2028 gerechnet. Bevor das neue Verb zu einem konkreten Standard im täglichen Betrieb wird, muss sich das gesamte Software-Ökosystem anpassen: Browser, CDNs und Server-Frameworks müssen ihre Bibliotheken aktualisieren, um die neue Methode korrekt zu erkennen und zu verarbeiten.

Darüber hinaus müssen noch potenzielle kritische Punkte gelöst werden, die eine Anpassung der Netzwerksicherheitssysteme erfordern:

• Blinde Flecken bei Firewalls: Herkömmliche Web Application Firewalls (WAFs) überprüfen den Nachrichtenkörper nur bei Methoden, die Daten verändern (POST, PUT). Da QUERY als sichere, schreibgeschützte Methode behandelt wird, besteht das Risiko, dass der Body ignoriert wird und Angriffe wie SQL Injection oder XSS durchgelassen werden;
• Umgehung von Anti-CSRF-Kontrollen: Da QUERY als „safe“-Methode eingestuft wird, ignorieren Anti-CSRF-Middleware sie standardmäßig. Wenn ein Entwickler den Endpoint fehlerhaft so implementiert, dass er Daten auf dem Server verändert, wird die Anwendung anfällig für CSRF-Angriffe;
• Preflight: QUERY gehört nicht zu den grundlegenden Methoden, die von Browsern automatisch zugelassen werden (safelisted). Aufrufe von unterschiedlichen Domains erfordern daher immer eine vorherige Kontrollanfrage (OPTIONS), wodurch sich die Netzwerkzeiten potenziell verdoppeln können.

In jedem Fall ist der Weg zur Implementierung der QUERY-Methode nun vorgezeichnet. Von nun an wird das HTTP-Protokoll komplexe Anfragen ermöglichen, ohne Ressourcen zu verändern, indem es die Flexibilität von POST mit den Garantien von GET hinsichtlich Lesbarkeit und Reproduzierbarkeit verbindet.