Die semantische Sünde, die wir alle begangen haben
Jahrzehntelang bedeutete das Abrufen von Daten oft, Suchparameter direkt in den URL-Abfrage-String eines GET request zu kodieren. Dieser Ansatz scheiterte schnell bei komplexen Suchen, die relationale Abfragen oder tief verschachtelte Daten umfassten. URLs blähten sich auf, stießen häufig an Browser- oder Server-Längenbeschränkungen und legten alle Parameter offen in Server-Logs und Browser-Verlauf dar.
Um URL-Beschränkungen zu umgehen, entwickelten Entwickler eine Problemumgehung: die Verwendung von POST requests, um komplexe Suchfilter im Request-Body zu transportieren. Dies führte jedoch zu einer erheblichen semantischen Verletzung. POST ist grundsätzlich dafür konzipiert, neue Ressourcen zu erstellen, nicht für das sichere, idempotente Abrufen vorhandener Daten.
Der Missbrauch von POST für Suchvorgänge hatte spürbare Folgen. Er unterbrach Caching-Mechanismen, da Proxys POST-Antworten aufgrund ihrer nicht-idempotenten Natur selten cachen. Darüber hinaus verhinderte seine nicht-idempotente Eigenschaft, dass Clients bei Netzwerkfehlern sichere automatische Wiederholungsversuche durchführen konnten, eine grundlegende Fähigkeit wirklich schreibgeschützter Operationen.
Ein weniger verbreiteter, aber ebenso problematischer Versuch bestand darin, einen Request-Body mit einer GET-Methode zu senden. Während die HTTP/1.1-Spezifikation dies mehrdeutig erlaubte, wurde explizit festgehalten, dass ein solcher Body „keine definierte Semantik“ besaß und „IGNORIERT WERDEN SOLLTE“. Dies machte „GET with a body“ zu einem unzuverlässigen, nicht standardisierten Mythos, der nie konsistente Unterstützung in der Web-Infrastruktur fand.
QUERY: GETs Sicherheit, POSTs Leistung
Schließlich traf die HTTP query-Methode (RFC 10008) ein, die im Juni 2026 formell standardisiert wurde. Sie repräsentiert die „fehlende Methode für die Suche“, speziell entwickelt, um die semantischen Problemumgehungen zu adressieren, die Entwickler seit über zwei Jahrzehnten verwendet haben. Dieses neue Verb zielt speziell auf komplexe, schreibgeschützte Datenabrufe ab.
Query kombiniert elegant die besten Eigenschaften seiner Vorgänger. Wie GET ist es sicher und idempotent, was bedeutet, dass es niemals den Serverzustand ändert und identische Anfragen stets dasselbe Ergebnis liefern. Diese Eigenschaft ermöglicht robuste Client-Wiederholungsversuche bei Fehlern. Entscheidend ist, dass es wie POST einen Request-Body akzeptiert, der ausreichend Platz für Abfrageparameter bietet.
Dieses hybride Design löst direkt das Kernproblem des Abrufs umfangreicher Daten. Entwickler können nun komplexe, tief verschachtelte Abfragestrukturen, wie z.B. JSON-Payloads, innerhalb des Request-Bodys senden. Dies vermeidet das Erreichen von Browser- oder Server-URL-Längenbeschränkungen und verhindert die Offenlegung sensibler Parameter in Logs. Entscheidend ist, dass es die semantische Verletzung der Verwendung von POST für nicht-zustandsändernde Operationen eliminiert und endlich einen standardisierten, cachefähigen und semantisch korrekten Ansatz für erweiterte API-Suchen bietet.
Intelligenteres Caching, bessere Sicherheit
QUERY bringt erhebliche betriebliche Vorteile über die semantische Korrektheit hinaus, insbesondere im Caching und bei der Sicherheit. Sein Design adressiert langjährige Herausforderungen, die GET und POST in komplexen Datenabrufszenarien plagten.
Antworten, die von einer QUERY-Methode generiert werden, sind vollständig cacheable und spiegeln die Effizienz von GET wider. Entscheidend ist, dass der gesamte Request-Body direkt in den Cache-Schlüssel einfließt. Dieser ausgeklügelte Mechanismus garantiert, dass jeder einzigartige Query-Body, unabhängig vom URI, einen eindeutigen Cache-Eintrag liefert, was einen präzisen und effizienten Datenabruf ermöglicht.
Ein integrierter Erkennungsmechanismus verbessert die Nützlichkeit von QUERY zusätzlich: der Accept-Query-Header. Server können nun explizit die spezifischen Abfrageformate bewerben, die sie unterstützen, was die Client-Server-Kommunikation optimiert und die API-Auffindbarkeit verbessert. Clients erhalten Klarheit über erwartete Syntaxen, was die Integrationsreibung reduziert.
Sicherheit und Datenschutz erfahren ebenfalls deutliche Verbesserungen. QUERY ist keine CORS-safelisted method und erfordert eine Preflight-OPTIONS-Anfrage für Cross-Origin-Aufrufe, was die Sicherheit von Webanwendungen stärkt. Noch wichtiger ist, dass sensible Abfrageparameter aus URLs ferngehalten werden, wodurch ihre Offenlegung in Server-Logs, Proxy-Aufzeichnungen und Browser-Verläufen verhindert wird – ein erheblicher Datenschutzgewinn gegenüber GET.
Dieses sorgfältige Design macht QUERY zu einer robusten Lösung für moderne API-Anforderungen. Für tiefere technische Spezifikationen verweisen wir auf RFC 10008: The HTTP QUERY Method, das seine vollständigen Fähigkeiten und Implikationen für die Webarchitektur detailliert beschreibt.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Der Weg zur Akzeptanz: Ein Realitätscheck
QUERY (RFC 10008) ist nun formell standardisiert, ein entscheidender Fortschritt für die HTTP-Semantik. Trotz dieser grundlegenden Errungenschaft befindet sich die weit verbreitete Akzeptanz im gesamten Web-Ökosystem noch in den Anfängen. Browser, verschiedene Web-Frameworks und Netzwerk-Proxys führen ihre Unterstützung für diese neue Methode schrittweise ein, ein Prozess, der bei einer grundlegenden Protokolländerung Zeit in Anspruch nimmt.
Die Dynamik nimmt deutlich zu, da wichtige Akteure QUERY bereits in ihre Plattformen integrieren. OpenAPI 3.2 unterstützt nun formell die QUERY-Methode, was Architekten und Entwicklern ermöglicht, diese leistungsstarken neuen Endpunkte direkt in ihren API-Spezifikationen zu definieren. Microsofts .NET 10 Framework bietet ebenfalls eine erste, robuste Unterstützung, was ein starkes Signal für eine breitere Framework-Integration ist und frühe Experimente fördert.
Organisationen sollten strategisch für die letztendliche Allgegenwart von QUERY planen. Für neue, komplexe schreibgeschützte Endpunkte sollte von Anfang an mit QUERY entworfen werden, aber robuste Fallbacks auf POST oder GET für die Kompatibilität implementiert werden. Schließlich sollten bestehende Web Application Firewalls (WAFs) und Proxy-Konfigurationen aktualisiert werden; diese Systeme müssen lernen, QUERY-Anfragen korrekt zu interpretieren, weiterzuleiten und zu cachen, um einen reibungslosen Betrieb zu gewährleisten.
Häufig gestellte Fragen
Was ist die neue HTTP QUERY-Methode?
Es ist ein neues, standardisiertes HTTP-Verb (RFC 10008), das für komplexe Such- und Datenabfragen entwickelt wurde. Es kombiniert die Sicherheit und Cache-Fähigkeit einer GET-Anfrage mit der Fähigkeit, einen Anfragekörper wie eine POST-Anfrage zu übermitteln.
Warum nicht einfach GET mit einem Anfragekörper verwenden?
Das Verhalten einer GET-Anfrage mit einem Körper ist in der HTTP-Spezifikation undefiniert. Dies führt zu inkonsistentem und unzuverlässigem Handling durch Server, Proxys und Caches, was es zu einer unpraktischen Lösung macht.
Ist die QUERY-Methode bereit für den Produktionseinsatz?
Noch nicht für die meisten Anwendungen. Obwohl sie offiziell standardisiert ist, befindet sich die weit verbreitete Unterstützung durch Browser, Server-Frameworks und Infrastruktur wie Proxys und WAFs noch in den Anfängen.
Wie verbessert QUERY das Caching gegenüber der Verwendung von POST für die Suche?
POST-Antworten werden im Allgemeinen nicht von Vermittlern wie Proxys oder CDNs zwischengespeichert. QUERY-Antworten sind explizit so konzipiert, dass sie cache-fähig sind, wobei der Inhalt des Anfragekörpers als Teil des Cache-Schlüssels verwendet wird, was die Leistung erheblich verbessert.