Die HTTP QUERY-Methode ist die lang erwartete Antwort auf ein altes Problem: sichere, idempotente Abfragen mit einem echten Request-Body. Seit Juni 2026 ist sie als RFC 10008 offiziell standardisiert und bei der IANA registriert, also längst kein bloßer Entwurf mehr. In der Praxis fehlt aber noch die Browser-Unterstützung, weshalb sie heute vor allem für Server-zu-Server-Kommunikation glänzt.
Worum geht's überhaupt? 🧐
Die HTTP QUERY-Methode ist eine neue HTTP-Methode, die etwas kann, das GET und POST bisher nie sauber zusammengebracht haben: Sie ist safe und idempotent wie GET, darf aber gleichzeitig einen Request-Body mitschicken wie POST. Damit schließt sie genau die Lücke, in der wir uns seit Jahren mit Hilfskonstruktionen behelfen.
Der typische Anwendungsfall ist die klassische Abfrage: komplexe Filter, Suchanfragen, GraphQL-Queries oder strukturierte Bedingungen, die zu groß für die URL werden. Bisher blieb dafür nur die Wahl zwischen zwei schlechten Optionen. Genau das räumt QUERY auf.
Das Problem: GET ist zu kurz, POST lügt 🤔
Schauen wir uns an, wie wir Abfragen heute lösen. Bei einer GET-Anfrage stecken alle Parameter in der URL, hinter dem Fragezeichen als Query-String. Das ist sauber, cachebar und idempotent, aber die URL-Länge ist begrenzt. HTTP definiert zwar kein hartes Limit, doch viele Server und Proxies kappen bei rund 8 KB (RFC 9110 empfiehlt eine Unterstützung von mindestens 8.000 Oktett). Ein verschachtelter Filter oder eine lange Liste von IDs sprengt das schnell.
Also greifen wir zu POST. Der Body ist beliebig groß, das Problem der URL-Länge ist gelöst. Aber POST ist semantisch eine kleine Lüge: Laut Spezifikation ist es weder safe noch idempotent noch sinnvoll cachebar. Wir signalisieren dem Server und jeder Zwischenschicht damit „hier ändert sich etwas", obwohl wir nur lesen wollen. Caches, Retries und Monitoring interpretieren das falsch, und wir verschenken jede Optimierung, die auf Sicherheit und Idempotenz aufbaut.
Was die HTTP QUERY-Methode anders macht 📦
QUERY nimmt das Beste aus beiden Welten. Die Anfrage trägt ihren Inhalt im Body, so wie bei POST, aber die Semantik ist die von GET. Die Spezifikation formuliert es so:
„A QUERY request asks the request target to process the enclosed content in a safe and idempotent manner and then respond with the result of that processing."
Der Body definiert die Abfrage, und der Content-Type beschreibt sein Format. Wichtig: Der Server muss die Anfrage ablehnen, wenn der Content-Type fehlt oder nicht zum Inhalt passt. Damit sind die Eigenschaften klar verteilt:
| Eigenschaft | GET | QUERY | POST |
|---|---|---|---|
| Safe | ja | ja | eventuell nein |
| Idempotent | ja | ja | eventuell nein |
| Cachebar | ja | ja | begrenzt |
| Request-Body | nein | ja | ja |
Ein echtes Beispiel 💻
So sieht eine QUERY-Anfrage aus, hier eine Kontaktsuche direkt aus RFC 10008:
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json
select=surname,givenname,email&limit=10&match=%22email=@example.%22Und die Antwort, ganz normales JSON:
HTTP/1.1 200 OK
Content-Type: application/json
[
{ "surname": "Smith",
"givenname": "John",
"email": "[email protected]" }
]Der Charme liegt im Body: Er kann beliebig komplex sein. Eine GraphQL-Query, ein JSON-Filterobjekt oder ein SQL-artiger Ausdruck, alles passt hier hinein, ohne die URL zu sprengen. Genau deshalb ist QUERY für GraphQL-über-HTTP so interessant, das bisher fast immer über POST läuft.
QUERY vs. POST: der direkte Vergleich ⚖️
Warum ist QUERY für Abfragen die bessere Wahl als POST, so wie es heute meistens gemacht wird? Es geht um vier Punkte, die im Alltag echten Unterschied machen:
| Aspekt | POST (für Reads) | QUERY |
|---|---|---|
| Semantik | signalisiert „verändert etwas" | signalisiert „liest nur" |
| Idempotenz | nein, Retry ist riskant | ja, Retry ist sicher |
| Cachebar | praktisch nein | ja, Cache-Key inklusive Body |
| Aussage an Proxies | irreführend | korrekt |
Kurz gesagt: POST funktioniert für Abfragen, aber es unterläuft die Garantien, auf denen das ganze HTTP-Ökosystem aufbaut. QUERY sagt die Wahrheit über die Anfrage, und Caches, Proxies, Load Balancer und Retry-Logik können sich darauf verlassen. Genau das ist der Kern: nicht ein neues Feature um seiner selbst willen, sondern ehrliche Semantik.
Nur ein Draft? Nein, jetzt RFC 10008 📜
Lange war QUERY genau das, ein Entwurf. Der IETF-Draft hieß draft-ietf-httpbis-safe-method-w-body und durchlief 14 Versionen in der httpbis-Arbeitsgruppe. Im Juni 2026 wurde daraus RFC 10008 mit dem Status Proposed Standard, geschrieben von Julian Reschke, James Snell und Mike Bishop.
Die IANA hat QUERY offiziell in die „HTTP Method Registry" aufgenommen, markiert als safe und idempotent. Es ist also eine vollwertige, standardisierte HTTP-Methode, kein Experiment mehr. Wenn du also liest, QUERY sei „nur ein Draft", ist das seit Juni 2026 nicht mehr korrekt.
Ein Haken bleibt: MDN hat die Methode noch nicht dokumentiert. Das entsprechende Ticket im MDN-Content-Repo wurde erst am 8. Juli 2026 eröffnet. Wer nach einer offiziellen MDN-Seite zu QUERY sucht, wird aktuell noch nicht fündig, die maßgebliche Referenz ist bis dahin der RFC selbst.
Kann ich das heute schon nutzen? 🛠️
Jein. Die Spezifikation ist fertig, die Werkzeuglandschaft holt gerade auf. Der Stand im Juli 2026:
- .NET 10 (LTS) bringt volle Client- und Server-Unterstützung mit, inklusive
HttpMethod.Queryund Parsing im Kestrel-Server. - Browser können QUERY noch nicht aus
fetchoder XHR senden. Genau das bremst öffentliche Web-APIs aktuell aus. - Proxies und CDNs: Cloudflare und Akamai haben den RFC mitgeschrieben, cachen QUERY-Antworten aber noch nicht zuverlässig im großen Stil.
In .NET sieht ein Client-Aufruf heute schon so aus:
using var request = new HttpRequestMessage(HttpMethod.Query,
"https://api.example.com/products/search")
{
Content = JsonContent.Create(filter)
};
using var response = await httpClient.SendAsync(request);
var page = await response.Content.ReadFromJsonAsync<ProductPage>();Ein wichtiger Stolperstein für den Browser-Einsatz ist CORS: Eine QUERY-Anfrage mit Body und eigenem Content-Type löst einen Preflight aus, den der Server korrekt beantworten muss. Wenn du dich mit dem Thema noch nicht auskennst, lohnt vorher ein Blick hierauf:
Mein Rat: Setze QUERY heute dort ein, wo du beide Seiten kontrollierst, also Server-zu-Server oder zwischen internen Microservices. Für öffentliche APIs, die Browser bedienen, wartest du besser noch, bis die Engines nachziehen.
Fazit 🚀
QUERY ist eine dieser Methoden, bei denen man sich fragt, warum es sie nicht längst gibt. Sie beendet den jahrelangen Missbrauch von POST für simple Abfragen und gibt uns endlich eine Methode, die safe, idempotent und cachebar ist und trotzdem einen Body tragen darf.
Mit RFC 10008 ist der Standard in trockenen Tüchern. Was jetzt noch fehlt, ist die Verbreitung in Browsern und Caches, und die kommt erfahrungsgemäß mit der Zeit. Wer APIs baut, sollte QUERY ab sofort auf dem Schirm haben. Tag gelaufen, ich freu mich drauf.