HTTP QUERY: die Methode, die endlich die Lücke zwischen GET und POST schließt

Die HTTP-Methode, die zwischen GET und POST gefehlt hat: sicher, idempotent, cachefähig, mit Body in der Anfrage. Vom Vorschlag zur IETF-Standardisierung.

Jeder, der schon einmal eine Such-API gebaut hat, kennt dieses Dilemma. Man möchte einen Endpunkt für komplexe Abfragen anbieten: mehrere Filter, Sortierungen, einen GraphQL-Ausdruck, vielleicht eine SQL-ähnliche Abfrage. Die erste Idee ist GET zu verwenden, semantisch die korrekte Methode: sicher, idempotent, cachefähig. Aber GET hat keinen definierten Body, also muss diese ganze Komplexität im URI landen, als Query-String. Das funktioniert, solange die Parameter wenige sind. Dann kommen die Längenbegrenzungen (unterschiedlich und unvorhersehbar je nach Client, Proxy und CDN), das Encoding verschachtelter Strukturen wird unleserlich, und sensible Daten landen im Klartext geloggt und als Lesezeichen speicherbar in der URL.

Also geben die meisten Entwickler auf und nutzen POST. Das funktioniert: der Body kann jede beliebige Struktur enthalten. Aber POST ist weder sicher noch idempotent: ein Vermittler kann nicht davon ausgehen, dass eine Wiederholung der Anfrage unschädlich ist, also kein automatisches Caching, keine sicheren Wiederholungsversuche, keine CDN-Optimierungen. Genau diese Wahl haben GraphQL, gRPC-over-HTTP, SOAP und XML-RPC seit Jahren getroffen: POST auch für reine Lesevorgänge zu verwenden, mit dem Preis bei Caching und Semantik.

Jahrelang war das ein akzeptierter Kompromiss. Am 19. Juni 2026 hörte er auf, einer zu sein: die IETF veröffentlichte RFC 10008, “The HTTP QUERY Method”, als Proposed Standard. Sehen wir uns an, woher dieser Vorschlag kommt, wie er im Detail funktioniert und was er für API-Designer heute bedeutet.

Die neue HTTP-QUERY-Methode öffnet einen Weg zwischen den bisher ausgetretenen Pfaden GET und POST.

Woher der Vorschlag kommt

Die Idee einer sicheren HTTP-Methode mit Anfrage-Body ist nicht neu: WebDAV machte das bereits 2003 mit SEARCH (RFC 5323), und noch früher mit PROPFIND und REPORT. Das Problem dieser Methoden ist, dass sie den gesamten semantischen Ballast von WebDAV mit sich tragen, gedacht für einen sehr spezifischen Namespace (Verwaltung von Ressourcen und Eigenschaften), und sich nicht gut auf den Rest des Webs verallgemeinern lassen.

Der Vorschlag einer generischen Methode, explizit dafür gedacht, die Lücke zwischen GET und POST in ganz HTTP zu schließen, kursiert seit mehreren Jahren in der HTTP-Working-Group-Community: die ersten öffentlichen Diskussionen reichen mindestens bis 2021 zurück, als der erste Draft (der später zu draft-ietf-httpbis-safe-method-w-body wurde) unter Entwicklern zu kursieren begann. Von dort durchlief er zahlreiche Überarbeitungen, vierzehn Draft-Versionen, Diskussionen auf der Mailingliste der HTTPbis Working Group und mehrere Runden von Last Calls, bis er im Juni 2026 zur offiziellen Veröffentlichung als RFC gelangte.

Die Autoren, drei Namen mit nicht geringem Gewicht im HTTP-Ökosystem, sind Julian Reschke (greenbytes, historisch Mitherausgeber der HTTP/1.1-Spezifikationen), James M. Snell (Cloudflare) und Mike Bishop (Akamai). Das Dokument wurde von der HTTPbis-Arbeitsgruppe der IETF gesponsert, mit Gorry Fairhurst als zuständigem Area Director.

Ein Detail, das die Autoren im Dokument explizit klarstellen: der gewählte Name ist “QUERY” und nicht eine der bestehenden WebDAV-Methoden (SEARCH, REPORT, PROPFIND), gerade um die semantische Mehrdeutigkeit dieser Methoden zu vermeiden und die konzeptuelle Verbindung zur Query-Komponente eines URI besser einzufangen, wodurch das Muster auf jede Art von Ressource verallgemeinert wird, nicht nur auf WebDAV.

Das Problem, das sie wirklich löst

Der zentrale Punkt, den RFC 10008 in der Einleitung schwarz auf weiß festhält, ist, dass keine der beiden klassischen Methoden den Fall komplexer, aber reiner Lesevorgänge gut abdeckt.

Die Grenzen von GET:

• die Längenbegrenzungen des URI sind weder klar noch einheitlich: sie variieren von Client zu Client, von Proxy zu Proxy, von CDN zu CDN, und sie zu überschreiten erzeugt schwer zu diagnostizierende Fehler;
• manche Datenstrukturen sind unbequem oder unmöglich korrekt in einem URI zu kodieren (tiefe Verschachtelung, Binärdaten, langer Freitext);
• Anfrage-URIs landen leichter geloggt, im Browserverlauf gespeichert oder als Lesezeichen, wodurch Daten offengelegt werden, die vielleicht nicht im Klartext in einem Log erscheinen sollten.

Die Grenzen von POST:

• sie ist weder sicher noch idempotent, sodass ein Client oder Vermittler die Anfrage nach einem Netzwerkfehler nicht automatisch wiederholen kann, ohne Nebenwirkungen zu riskieren;
• sie ist standardmäßig nicht cachefähig, was die Arbeit von CDNs und Reverse-Proxys vor APIs erheblich erschwert, die de facto immer nur lesbare Daten zurückgeben;
• semantisch ist sie mehrdeutig: ein Client kann allein anhand der Methode nicht ableiten, ob ein POST etwas erstellt, ändert, löscht oder einfach nur liest.

QUERY übernimmt den Body von POST und die Sicherheit/Idempotenz von GET, bleibt dabei aber auch cachefähig: die Kombination, die GraphQL und Verwandte de facto seit Jahren versuchen, mit POST als Workaround zu simulieren.

Wie sie in der Praxis funktioniert

Eine QUERY-Anfrage sieht aus wie eine POST, aber mit der expliziten Garantie, dass der Server den Zustand der Zielressource nicht verändert. Der Content-Type ist verpflichtend, weil er das Format definiert, in dem die Abfrage ausgedrückt ist: das kann JSON sein, ein anwendungsspezifisches Format wie application/graphql, ein strukturiertes Abfrageformat wie application/jsonpath, oder auch reiner Text.

Ein Beispiel mit einer GraphQL-Abfrage:

QUERY /api/graphql HTTP/1.1
Content-Type: application/graphql

{ users(role: "admin") { id name email } }

Ein Beispiel mit einem strukturierten JSON-Suchfilter:

QUERY /feed HTTP/1.1
Content-Type: application/json

{
   "q": "distributed systems",
   "limit": 10,
   "sort": "-published",
   "filters": ["status:active", "type:post"]
}

Und ein Beispiel, das eher einer SQL-artigen Abfrage ähnelt, mit einer CSV-Antwort:

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv

select surname, givenname, email limit 10

Wenn der Server den gesendeten Content-Type nicht versteht oder nicht akzeptiert, antwortet er mit präzisen Fehlercodes: 400 Bad Request, wenn der Header fehlt oder inkonsistent ist, 415 Unsupported Media Type, wenn das Format nicht unterstützt wird, 422 Unprocessable Content, wenn die Syntax gültig, aber die Abfrage nicht verarbeitbar ist, 406 Not Acceptable, wenn er keine Antwort im vom Accept des Clients angeforderten Format erzeugen kann.

Der Accept-Query-Header

RFC 10008 führt außerdem einen neuen Antwort-Header ein, Accept-Query, mit dem eine Ressource sowohl die Unterstützung der QUERY-Methode als auch die akzeptierten Abfrageformate deklariert, unter Verwendung der Syntax der Structured Field Values (RFC 9651):

HTTP/1.1 200 OK
Allow: GET, QUERY
Accept-Query: application/json, application/graphql

Cache, Bedingungen und Redirects

Hier liegt ein guter Teil des praktischen Werts der Methode. Der Cache-Schlüssel einer QUERY-Antwort umfasst, neben der Ziel-URI, auch den Inhalt der Anfrage und relevante Metadaten: zwei unterschiedliche Abfragen auf demselben Endpunkt erzeugen unterschiedliche Cache-Einträge, aber identische Abfragen können aus dem Cache bedient werden, ohne das Backend zu berühren.

QUERY unterstützt auch bedingte Anfragen, genau wie GET: ein Client kann If-None-Match mit einem ETag senden und 304 Not Modified erhalten, wenn sich das Ergebnis nicht geändert hat, oder If-Modified-Since, If-Match, If-Unmodified-Since und sogar Range-Requests verwenden.

Um die Antwort mit einer konkreten, wiederverwendbaren Ressource zu verknüpfen, hat der Server drei Möglichkeiten:

1. einen Content-Location-Header einfügen, der auf eine mit einer nachfolgenden GET abrufbare Ressource verweist;
2. einen Location-Header für in Zukunft wiederholbare Abfragen einfügen;
3. mit einem 303 See Other-Redirect auf eine über GET erreichbare URI antworten.

Und hier gibt es einen interessanten Unterschied zum klassischen Redirect-Verhalten: QUERY erhält seine eigene Methode über 301-, 302-, 307- und 308-Redirects hinweg (ein Client, der diesen Redirects folgt, wiederholt eine QUERY, wandelt sie nicht in GET um). Nur 303 konvertiert die nachfolgende Anfrage explizit zu GET, was genau der Mechanismus ist, der dafür gedacht ist, das Ergebnis einer Abfrage als eigenständige Ressource zu “materialisieren”.

Ein Detail, das man im Hinterkopf behalten sollte, wenn man mit öffentlichen, im Browser exponierten APIs arbeitet: QUERY ist nicht CORS-safelisted, sodass Cross-Origin-Anfragen ein OPTIONS-Preflight erfordern, genau wie es heute bereits bei vielen POST-Anfragen mit nicht-einfachem Content-Type der Fall ist.

Wo die Adoption steht

Die Veröffentlichung eines RFC als Proposed Standard bedeutet nicht, dass am nächsten Tag das gesamte Ökosystem ihn unterstützt. Es ist die erste Stufe der IETF-Standards-Track: die Spezifikation ist stabil und implementierungsbereit, aber es braucht Zeit, bis Browser, Server, Proxys, CDNs und Client-Bibliotheken sie tatsächlich adoptieren.

Aktuell implementiert kein großer Browser QUERY nativ. Serverseitig bewegt sich die Situation schneller: Node.js hat die Unterstützung der Methode bereits während der Draft-Phase in sein http-Modul aufgenommen, und Go unterstützt dank der Bauweise von net/http de facto jede benutzerdefinierte Methode (einschließlich QUERY) über http.NewRequest, ohne dass Änderungen an der Standardbibliothek nötig sind. Direkt nach der Veröffentlichung des RFC eröffneten Framework-Communities wie Ruby on Rails öffentliche Diskussionen, um eine native Unterstützung zu prüfen.

Ein für die Leser dieses Blogs relevanter Fall: auch DMVCFramework, das Referenz-REST/MVC-Framework für Delphi, hat bereits eine Untersuchung laufen, um die Unterstützung der QUERY-Methode zu bewerten und zu entwerfen. Wer diese technischen Entscheidungen genau verfolgen, mitdiskutieren oder konkrete Anwendungsfälle vorschlagen möchte, findet den richtigen Ort auf dem Patreon von DMVCFramework: dort teile ich diese Arbeit im Vorabblick, bevor sie öffentlich wird.

Das zu erwartende Muster ist dasselbe, das man bereits bei anderen HTTP-Methoden und -Headern gesehen hat, die in den letzten zwanzig Jahren zum Standard wurden: zuerst serverseitige Adoption und Entwickler-Tools, dann Konsolidierung in Frameworks, schließlich, langsamer, native Browser-Unterstützung und JavaScript-APIs wie fetch(). In der Zwischenzeit kann, wer experimentieren möchte, das bereits serverseitig tun: HTTP hat auf Ebene des Transportprotokolls nie benutzerdefinierte Methoden verhindert, daher ist die Implementierung eines Endpunkts, der auf QUERY antwortet, heute bereits mit den meisten serverseitigen Stacks möglich, vorausgesetzt man berücksichtigt Clients, zwischengeschaltete Proxys und CDNs, die die Methode vielleicht noch nicht kennen und sich unvorhersehbar verhalten könnten.

Was das für API-Designer bedeutet

Für alle, die heute an REST-APIs oder GraphQL-artigen Endpunkten arbeiten, ist QUERY keine Dringlichkeit, aber eine Methode, die man aufmerksam im Auge behalten sollte, weil sie ein reales, weit verbreitetes Problem löst, ohne ein neues Format oder Protokoll einzuführen, nur ein fehlendes Puzzlestück von HTTP. Einige praktische Überlegungen:

• Es ist (noch) nicht die Zeit, Produktionstraffic zu ersetzen. Da null Browser sie nativ unterstützen, läuft jede reale Nutzung heute über benutzerdefinierte HTTP-Clients oder Server-zu-Server-Bibliotheken, nicht über ein Formular oder ein fetch() in einem generischen Browser.
• Sie ist ein natürlicher Kandidat für interne oder Server-zu-Server-Endpunkte. Wenn man sowohl den Client als auch den Server kontrolliert, etwa in einer Microservices-Architektur, kann man schon heute korrekte Semantik und Caching bei komplexen Abfragen erreichen, ohne auf Browser-Unterstützung zu warten.
• Sie vereinfacht das Design von Such-APIs und GraphQL-artigen APIs. Statt POST für reine Lesevorgänge zu erzwingen, bietet QUERY endlich eine semantisch korrekte Art auszudrücken: “Ich lese, mit einer komplexen Abfrage, und diese Anfrage ist sicher zu wiederholen und zu cachen.”
• Man muss auf der Infrastrukturseite nichts neu erfinden. Da es sich einfach um eine neue HTTP-Methode handelt, funktioniert die gesamte bestehende Infrastruktur, die auf Standard-Headern basiert (Cache, ETag, Redirects, Content Negotiation), weiter, sofern die verschiedenen Vermittler auf dem Weg sie korrekt erkennen.
• Das Gespräch zwischen einem Delphi-Client und einem DMVCFramework-Server. Ein sehr konkreter Fall für alle, die mit Delphi arbeiten: eine Desktop-Anwendung (VCL oder FMX), ein Windows-Dienst oder ein anderer Server, geschrieben in Delphi oder in jeder anderen Sprache, der ein DMVCFramework-Backend mit differenzierten Suchfiltern abfragen muss (mehrere Felder, Datumsbereiche, Sortierungen, Pagination). Heute ist die Wahl zwischen einer GET mit einem umständlich zu konstruierenden und potenziell zu langen Query-String, oder einer POST, die auf Caching und Idempotenz verzichtet, nur um den Filter in den Body “hineinzuquetschen”. Mit QUERY kann dieser Client den Filter als strukturierten Body (typischerweise JSON) an den DMVCFramework-Endpunkt senden und erhält korrekte Semantik, sichere Wiederholungsversuche bei Netzwerkfehlern und die reale Möglichkeit, Cache und Reverse-Proxys vor dem Server zu nutzen, was mit POST heute nicht möglich ist.

Die wichtigsten Punkte

• Die Lücke zwischen GET und POST hat jetzt einen Namen. QUERY kombiniert den Body von POST mit der Sicherheit und Idempotenz von GET und bleibt dabei auch cachefähig.
• Es ist Realität, nicht mehr nur ein Vorschlag. RFC 10008, “The HTTP QUERY Method”, wurde von der IETF am 19. Juni 2026 als Proposed Standard veröffentlicht.
• Es kommt nicht aus dem Nichts. Es ist konzeptuell von WebDAVs SEARCH (RFC 5323, 2003) inspiriert, verallgemeinert das Muster aber auf das gesamte Web mit einem neuen Namen und ohne WebDAV-Ballast.
• Es hat eine präzise Syntax. Verpflichtender Content-Type, neuer Accept-Query-Header zur Deklaration der unterstützten Formate, dedizierte Fehlercodes (400, 415, 422, 406).
• Es erhält Caching und Sicherheit von HTTP. Cache-Schlüssel basierend auf Inhalt und URI, bedingte Anfragen, Redirects, die die Methode erhalten (außer 303).
• Die Adoption steht noch am Anfang. Noch kein nativer Browser, aber Node.js und Go unterstützen sie bereits serverseitig, und Frameworks wie Ruby on Rails und DMVCFramework (für Delphi) prüfen die Einführung.

Häufig gestellte Fragen

Was ist die HTTP-QUERY-Methode?

QUERY ist eine neue HTTP-Methode, standardisiert als RFC 10008, mit der eine Anfrage mit Body gesendet werden kann (wie POST), aber mit sicherer und idempotenter Semantik (wie GET). Der Server verarbeitet den Inhalt der Anfrage und antwortet mit dem Ergebnis, ohne den Zustand der Zielressource zu verändern.

Worin unterscheidet sie sich von GET und POST?

GET ist sicher und idempotent, hat aber keinen definierten Body, sodass komplexe Abfragen im URI landen, mit unbequemen Längenbegrenzungen und Encoding. POST akzeptiert einen Body, ist aber weder sicher noch idempotent, also nicht cachefähig und kann nicht automatisch sicher wiederholt werden. QUERY übernimmt den Body von POST und die Sicherheit/Idempotenz von GET, bleibt dabei aber auch cachefähig.

Wurde die QUERY-Methode offiziell akzeptiert?

Ja. Am 19. Juni 2026 veröffentlichte die IETF den RFC 10008, “The HTTP QUERY Method”, als Proposed Standard, die erste Stufe der IETF-Standards-Track. Die Autoren sind Julian Reschke, James M. Snell und Mike Bishop, erarbeitet von der HTTPbis-Arbeitsgruppe. Die Methode ist nun im IANA HTTP Method Registry als safe und idempotent registriert.

Unterstützen Browser und Frameworks QUERY schon?

Die Unterstützung steckt noch in den Anfängen. Kein großer Browser implementiert sie zum Zeitpunkt der RFC-Veröffentlichung nativ. Node.js hat serverseitige Unterstützung in seinem http-Modul hinzugefügt, Go unterstützt sie bereits wie jede benutzerdefinierte Methode über http.NewRequest, und Communities wie die von Ruby on Rails haben direkt nach der RFC-Veröffentlichung Diskussionen eröffnet, um sie hinzuzufügen. Eine schrittweise Adoption wird in den kommenden Monaten/Jahren erwartet, nicht sofort.

Warum nicht WebDAV-Methoden wie SEARCH, REPORT oder PROPFIND wiederverwenden?

Weil sie den semantischen Ballast von WebDAV mit sich tragen (RFC 5323, RFC 3253, RFC 4918), das für einen sehr spezifischen Namespace gedacht war, und die konzeptuelle Verbindung zur Query-Komponente eines URI nicht gut einfangen. Die Autoren von RFC 10008 haben bewusst einen neuen Namen gewählt, QUERY, um genau diese Mehrdeutigkeit zu vermeiden und das Muster auf das gesamte Web zu verallgemeinern.

Wird DMVCFramework die QUERY-Methode unterstützen?

Es läuft bereits eine Untersuchung, um die Unterstützung der QUERY-Methode in DMVCFramework, dem REST/MVC-Framework für Delphi, zu bewerten und zu entwerfen. Wer diese Arbeit genau verfolgen, mitdiskutieren oder Anwendungsfälle vorschlagen möchte, kann dem Patreon von DMVCFramework beitreten.

Quellen und weiterführende Informationen: IETF, RFC 10008, “The HTTP QUERY Method” (Juni 2026); IETF Datatracker, Dokument-Tracking-Seite; http.dev/query; kmcd.dev, “The HTTP Query Method”; Anton Oko, “HTTP QUERY: A New Method For Search Queries” auf Medium; Dan Horovits, “HTTP’s New Method for Data APIs: HTTP QUERY” auf Medium; Diskussion auf Hacker News.