HTTP QUERY

QUERY ist eine HTTP-Methode, die wie GET sicher und idempotent ist, ihre Eingabe aber als Request-Body überträgt, damit eine lesende Abfrage nicht in die URL passen muss.

Sie steht genau zwischen den beiden Methoden, die du ohnehin benutzt: Sie liest wie GET und verändert auf dem Server nichts, und sie trägt einen Körper wie POST. Der Unterschied zu POST liegt nicht im Format, sondern in der Zusage. Eine QUERY-Anfrage erklärt, dass sie nur liest.

Das Problem davor

Bevor es QUERY gab, hatte eine lesende Anfrage mit Body genau eine Option: POST. Eine Suche mit zwei Dutzend Filtern, ein GraphQL-Dokument, eine Analytics-Abfrage mit verschachteltem Zeitraum, nichts davon passt in eine URL, die Proxys, Server und Browser noch akzeptieren. Also ging es als POST raus.

Das funktionierte, und es log. POST sagt jeder Schicht auf dem Weg, dass die Anfrage etwas verändert. Die Folgen sind praktisch, nicht akademisch:

Die Antwort ist nicht so cachebar, wie es einem Lesezugriff zustünde, weil der Cache-Schlüssel die URI ist und der Body für ihn nicht existiert.
Proxys, Gateways und Web Application Firewalls stufen die Anfrage als Schreibzugriff ein und wenden Schreibregeln darauf an.
Ein automatischer Wiederholungsversuch nach einem Timeout ist nicht mehr unbedenklich, weil nichts an der Anfrage sagt, dass sie gefahrlos wiederholbar ist.

QUERY nimmt die Notlüge heraus. Gleicher Body, ehrliche Semantik.

GET, POST und QUERY nebeneinander

	Sicher	Idempotent	Body erlaubt	Cachebar
GET	ja	ja	ohne definierte Bedeutung	ja, Schlüssel ist die URI
POST	nein	nein	ja	nur mit ausdrücklichen Cache-Vorgaben
QUERY	ja	ja	ja	ja, Schlüssel schließt den Body ein

Die letzte Zelle ist die praktisch wichtigste. RFC 10008 verlangt, dass der Cache-Schlüssel einer QUERY-Anfrage den Inhalt des Requests einbezieht. Erst das macht einen zwischengespeicherten Lesezugriff mit Body überhaupt möglich.

Wo QUERY praktisch auftaucht

Suchen mit langen Filtersätzen. GraphQL-Endpunkte, die seit Jahren als POST beschrieben werden, obwohl sie nichts tun als lesen. Analytics- und Reporting-APIs, deren Parameter die Längengrenzen der Zwischenstationen sprengen. Alles, was eine Frage beantwortet, statt eine Antwort zu verändern.

Standardisierung

QUERY ist in RFC 10008, "The HTTP QUERY Method", spezifiziert, veröffentlicht im Juni 2026 als Proposed Standard auf dem IETF-Standards-Track. Vorher lief die Arbeit in der httpbis-Arbeitsgruppe unter dem Entwurfsnamen "safe method with body". Server und Frameworks ziehen erst nach und nach nach. Deshalb antwortet ein Ziel, das die Methode nicht kennt, mit 405 Method Not Allowed, einem der HTTP-Statuscodes, auf die zu achten sich lohnt.

Was das fürs Monitoring bedeutet

Ein Monitor, der einen Suchendpunkt mit POST prüft, berichtet über eine Anfrage, die in der Produktion niemand stellt, und läuft womöglich in dieselben Schreibregeln, die ein echter Nutzer nie berührt. Mit QUERY beschreibt die Prüfung den Endpunkt, den sie prüft. Bei Uptimeify steht QUERY in der Methodenauswahl jedes HTTP-Monitors neben GET, mit demselben Body-Feld, das POST bekommt. So deckt Uptime-Monitoring auch Abfrage-Endpunkte so ab, wie sie tatsächlich gebaut sind.