Zestien jaar lang zaten ontwikkelaars die complexe vragen aan een server moesten stellen vast aan een workaround. Wanneer een

Zestien jaar lang zaten ontwikkelaars die complexe vragen aan een server wilden stellen vast aan een workaround. Wanneer een zoekpayload te groot werd voor een URL, of wanneer geneste filters en gevoelige parameters niet in een querystring pasten, was POST de enige praktische optie. Het vervoerde de bytes, maar het loog over de intentie. POST signaleert een toestandswijziging. Het gebruiken ervan voor een alleen-lezen operatie dwong het volledige netwerkpad — caches, proxies en browsers — om een onschuldige zoekopdracht te behandelen alsof deze een database zou kunnen wijzigen.

Dat compromis is eindelijk voorbij. In juni 2026 publiceerde het IETF RFC 10008, waarmee de QUERY-methode formeel werd gestandaardiseerd. Het is de eerste nieuwe HTTP-methode sinds de introductie van PATCH in 2010. QUERY bestaat specifiek voor veilige, idempotente verzoeken die toevallig een body nodig hebben. Het wijzigt de servertoestand niet. Het herhalen van hetzelfde verzoek levert hetzelfde resultaat op. Het is cachebaar, wat betekent dat tussenliggende systemen het antwoord kunnen opslaan en hergebruiken. En in tegenstelling tot GET staat het een datapayload toe, net als POST.

GraphQL-queries en complexe REST-zoekendpoints zijn de grootste winnaars. Je hoeft niet langer zestig queryparameters in een URL te proppen of een JSON-filterdocument te verbergen in een POST-body die tussenliggende systemen weigeren te cachen. De semantiek is nu eerlijk.

Maar een RFC is slechts inkt op papier. Tussen je applicatie en je gebruikers zit een dikke laag infrastructuur, en het grootste deel daarvan heeft nog nooit van QUERY gehoord.

Het cachingprobleem is nog niet opgelost

Bij een GET-verzoek is caching eenvoudig. De cache-key is de URI. Twee gebruikers die dezelfde URL aanroepen, krijgen hetzelfde opgeslagen antwoord, ervan uitgaande dat de headers dit toestaan.

QUERY doorbreekt dat model omdat de verzoekparameters in de body staan. Om te herkennen dat twee verzoeken identiek zijn, moet de cache-key zowel de URI als de inhoud van de body bevatten. Die vereiste zorgt voor echte operationele frictie.

Ten eerste moeten edge-servers en CDN's de volledige request body bufferen voordat ze een hash kunnen berekenen. Dat kost geheugen en tijd bij de edge node. Ten tweede kunnen twee logisch identieke queries verschillende bytes produceren. De ene client stuurt mogelijk {"status":"active"} terwijl een andere {"status": "active"} stuurt met een andere witruimte of volgorde van keys. Tenzij de cachinglaag de body parseert, normaliseert en canonicaliseert — het sorteren van JSON-keys, het verwijderen van onbeduidende opmaak en het afhandelen van encoding-verschillen — zal dezelfde vraag de cache elke keer missen.

Cruciaal is dat mainstream CDN's de cache nog niet partitioneren op basis van de request body voor QUERY. Cloudflare behandelt de body bijvoorbeeld in zijn huidige vorm niet als onderdeel van de cache-key voor deze methode. Als je QUERY implementeert in de veronderstelling dat cachebaar ook echt gecached betekent, kun je collision errors, universele cache misses of antwoorden zien die lekken naar ongerelateerde verzoeken. Totdat je provider expliciete ondersteuning publiceert, moet je ervan uitgaan dat QUERY in productie niet betekenisvol cachebaar is.

Je tools zullen het waarschijnlijk als eerste blokkeren

Elk HTTP-verzoek gaat door een stapel middleboxes, en de meeste daarvan handhaven strikte regels over welke methoden toegestaan zijn.

Web Application Firewalls en API-gateways vertrouwen vaak op expliciete allowlists. Een typische set regels staat GET, POST, PUT, DELETE en PATCH toe. Alles wat anders is, wordt gedropt of beantwoord met een 405 Method Not Allowed. QUERY zal tegen deze muren aanlopen voordat het je applicatiecode bereikt.

Security rule engines vormen een extra obstakel. Sommige intrusion detection-systemen gaan ervan uit dat een verzoek met een body