Wozu noch eine HTTP-Methode?
GET oder POST – das Thema taucht in praktisch jedem API-Projekt wieder auf. GET reicht, solange die Filter halbwegs übersichtlich bleiben. Aber sobald Parameterlisten ausufern, bekommt man schnell Stress mit URL-Limits. Je nach Stack mal 2.048, mal 8.000 Zeichen – irgendwann ist Schluss. Dann fängt das Gefrickel an: Kürzen, umsortieren, Parameter splitten. POST geht zwar immer, aber das fühlt sich für reine Leseabfragen oft falsch an. Caching? Wird komplizierter. Mit RFC 10008 kam 2026 die Methode QUERY ins Spiel. Neue Idee: Komplexe Filter einfach in den Body packen, aber trotzdem alles lesend, keine Seiteneffekte.
Klingt elegant. Filter und Parameter endlich nicht mehr in die URL quetschen, sondern sauber im Body mitgeben. Die Theorie: Leseabfragen bleiben klar getrennt, POST bleibt für Änderungen. API-Design wird aufgeräumter. Aber wie praxistauglich ist das Ganze?
QUERY im Alltag – was klappt, was hakt?
QUERY nimmt einem die Limitierung der URL ab. Analytics-APIs, Suchabfragen mit Dutzenden Parametern, JSON-Filter für Reports – alles im Body. Semantik bleibt: lesen, nicht schreiben. Vorteil: Caching kann ähnlich wie bei GET funktionieren, zumindest wenn das CDN oder der Edge-Cache QUERY versteht.
Typische Anwendungen:
- APIs mit vielen oder zu langen Parametern für GET
- Such- und Analyse-Endpunkte mit komplexen Filtern
- Lese-APIs, wo GET endgültig an Grenzen stößt
So weit die Theorie. In der Praxis 2026: Die Unterstützung ist löchrig. Browser? Kaum. Standard-HTTP-Clients? Teilweise. Viele Proxies, Loadbalancer, Firewalls kennen QUERY nicht oder blocken aus Prinzip alles Unbekannte. Tools wie curl, Postman oder Browser-Netzwerkmonitore? Zum Teil nachgerüstet, aber oft muss man basteln oder Workarounds nutzen.
Was QUERY besser macht als GET und POST
Der größte Pluspunkt: Endlich Schluss mit abgeschnittenen URLs oder Workarounds à la POST für Leseabfragen. Filter beliebig verschachteln, Datenmengen in den Body – kein Problem mehr. Das API-Design wird dadurch sauberer: Lesend per QUERY, schreibend per POST/PUT/PATCH. Caching regelt sich einfacher, sofern das Tooling mitspielt.
Gerade bei APIs mit vielen Filtern ist das ein Segen. Beispiel: Eine Such-API, die flexible Reports zusammenstellen muss. Bisher landet man schnell bei POST-Requests, obwohl keine Daten geändert werden. QUERY verhindert das Durcheinander.
Hürden – was aktuell noch bremst
- Unterstützung: Viele HTTP-Stacks, Proxies und CDN-Systeme kennen QUERY nicht. Teilweise blockt bereits der Webserver.
- Tools: Debugging und Testing sind mühsam, solange gängige Tools mit QUERY nicht zurechtkommen. curl, Postman – überall gibt es noch Lücken.
- Firewalls: Für Bodies bei Leseoperationen fehlen oft die richtigen Filterregeln. Manche WAFs machen sofort dicht.
- Legacy und Partner: Schnittstellen zu externen Systemen? Oft Fehlanzeige bei unbekannten Methoden – Ablehnung oder Fehlverhalten sind die Folge.
Meine Einschätzung nach fast 30 Jahren Webentwicklung
GET-Limits und POST-Hacks sind seit Ewigkeiten Alltag. In Projekten mit großen Filtermengen war das schon immer ein Krampf. Klar, QUERY bringt Ordnung: Endlich keine Notlösungen mehr, keine Angst vorm nächsten URL-Overflow. Aber: In Shared-Hosting-Umgebungen oder Managed-Stacks kommt man 2026 mit QUERY selten weit. Eigene Server? Da lässt sich schneller nachrüsten, aber auch hier: Proxies, Firewalls, Monitoring müssen angepasst werden. Bei Agenturen mit mehreren Kundenprojekten lohnt sich QUERY nur für neue APIs, nicht als Retro-Fit. Aufwand und Risiko? Oft zu hoch, solange das Tooling nicht nachgezogen hat.
Was jetzt konkret zu beachten ist
- API-Design: QUERY nützt, wenn Filterlisten explodieren oder GET regelmäßig streikt.
- Infrastruktur: Ohne Support im Webserver, Proxy oder CDN bleibt alles Theorie. Erst prüfen, ob QUERY überhaupt ankommt.
- Toolchain: Tests, CI/CD, Monitoring – alle Tools müssen QUERY verstehen. Updates oft unumgänglich.
- Kundenprojekte: QUERY als Option für neue APIs — aber nur mit Vorwarnung an alle Beteiligten. Zeitpuffer einplanen.
- Zusammenarbeit: Externe Partner und SaaS-Dienste vorher checken – nicht überall klappt QUERY out of the box.
Fazit: Praktisches Werkzeug, aber kein Wundermittel
QUERY räumt mit dem länglichen GET-POST-Gefrickel auf. Für große, moderne APIs ein spürbarer Fortschritt, aber Stand 2026 eben noch kein Selbstläufer. Kompatibilität? Oft Glückssache. Wer auf Nummer sicher gehen muss, bleibt besser bei GET oder POST. QUERY lohnt, wo Filterstrukturen wirklich ausufern – und nur, wenn die Infrastruktur mitzieht. Für kleine Projekte? Meist unnötig. Für ambitionierte neue APIs? Im Blick behalten, aber nicht blind einbauen.
Mehr zu HTTP-Standards und Performance gibt’s hier: HTTP/2 und HTTP/3 2026: Protokolle als unsichtbarer Flaschenhals – mit Details zu Protokollen, Flaschenhälsen und was im Alltag wirklich bremst.
bye
mo