HTTP QUERY Finally Settles the Argument. Your Infrastructure Gets the Next One.

There is a meeting that happens in every engineering org, roughly once a quarter, forever. Someone is designing a search endpoint. The filter object is large and structured: date ranges, nested facets, a list of tenant IDs longer than any sane URL. And so the question arrives, on cue, like a season finale you have already seen fifteen times.

“Do we send the filter as a body on GET, or do we just make it a POST?”

Then the room splits. One faction wants the body on GET, because a search is a read, and reads should be safe, idempotent, and cacheable. The other faction points out, correctly, that a body on GET has no defined semantics (Fielding et al., 2022), that some proxies quietly drop it, and that you are building on sand. So the room retreats to POST, everybody feels slightly dirty about it, and the search endpoint ships as a POST that is secretly a read. The caching story is now your problem forever.

I have been in that meeting more times than I can count. As of June 2026, it is over. RFC 10008 defines the HTTP QUERY method (Reschke et al., 2026), and it settles the argument cleanly. I want to be honest about what it settles, because the useful part is not the part everyone is quoting.

What the method actually is

QUERY is a request method that carries content in the request body, like POST, but is explicitly defined as safe and idempotent, like GET. The abstract puts it plainly: a QUERY asks the target to process the enclosed content in a safe and idempotent manner and return the result, and unlike POST it can be automatically repeated or restarted without concern for partial state changes (Reschke et al., 2026).

That single sentence is the whole point. Safe means the request is not expected to change server state. Idempotent means a client, a proxy, or a flaky mobile connection can retry it without booking a second charge or creating a duplicate. POST gives you neither guarantee, which is why every retry layer treats POST with suspicion. GET gives you both, but will not carry your 4 KB filter object in a way anyone has agreed on.

Here is the search endpoint everyone actually builds today.

POST /feed HTTP/1.1
Host: example.org
Content-Type: application/json

{ "since": "2026-01-01", "tenants": [11, 42, 108], "facets": ["status", "region"] }

Listing 1. The search-as-POST that ships in most codebases, a read wearing a write's clothing.

And here is the same request as QUERY, taken from the shape the RFC itself uses (Reschke et al., 2026).

QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/json

{ "since": "2026-01-01", "tenants": [11, 42, 108], "facets": ["status", "region"] }

Listing 2. The same request as QUERY: identical body, honest semantics.

The body is identical. The difference is that the second one tells the truth about what it does.

The properties, and why they end the argument

Your instinct to line these up in a table was correct. Here is the version I would put on the whiteboard, reconciled against the comparison table the RFC ships in its own text.

Two cells are worth a second look, because they are where the honesty lives.

The body row is the reason the argument existed at all. GET does not forbid a body, it simply assigns it “no defined semantics,” which is standards language for “you are on your own and do not come crying to us.” QUERY defines the body as the substance of the request. That is the gap POST used to fill by accident, now filled on purpose.

The caching row is the one people are quoting too confidently, so let me spoil the party.

The asterisk on cacheable

QUERY responses are cacheable. That is real, and it is the headline feature. But a cache that stores a QUERY response has to key on the request body, not just the method and URL, because the body is the query. Most of the caching infrastructure deployed in the world today does not do that. It was built for GET, where the URL is the whole identity of the request.

The RFC has an answer, and it is worth knowing because it changes how you design the endpoint. A server can hand back a Content-Location pointing at a URI that represents the result, so a client can follow up with an ordinary, boringly cacheable GET (Reschke et al., 2026). There is also a new Accept-Query response header so a resource can advertise that it speaks QUERY and say which query formats it accepts.

Accept-Query: application/json, application/sql

Listing 3. A resource advertising QUERY support and the formats it accepts.

So “cacheable: yes” is true, and it is also a small project. The method gives you the semantics for free. The caching benefit you have to actually plumb through your stack. Hold that thought, because it is the whole second half of this post.

We had this in 2008 and flinched

The comedic framing going around is that HTTP waited decades to give us a method it always needed. That is nearly right, and the accurate version is funnier. We did not wait. We had it.

WebDAV shipped a SEARCH method in 2008 for exactly this problem: a safe request with a body describing what to look for (Reschke et al., 2008). The early drafts of this very specification were also called SEARCH before the working group settled on QUERY, partly because the WebDAV lineage made people uneasy (Reschke et al., 2026). So the honest history is not that HTTP starved us for fifteen years. It is that HTTP offered us a perfectly good fork in 2008, the fork said “WebDAV” on the handle, we recoiled, and we spent the next decade and a half arguing in meeting rooms instead. QUERY is SEARCH with a better haircut and a cleaner spec, and this time nobody has to say the word WebDAV out loud.

The argument does not end, it moves down a layer

Here is where I stop agreeing with the celebration and start reading the room.

A method is only as real as the software that speaks it. QUERY the specification is settled. QUERY the deployed reality is a green field with three fence posts in it. On the day I am writing this, your browser fetch call, your HTTP client library, your API gateway, your load balancer, your WAF, and your CDN mostly do one of two things with QUERY: reject it, or pass it through as an opaque method they do not understand and therefore do not cache. The moment your endpoint needs to work for a caller you do not control, you are shipping a POST fallback anyway, and you are back in a version of the old meeting.

So the argument I have been having for years is genuinely settled at the semantic layer, and it reopens instantly one layer down. It stops being “which method is correct” and becomes “does our edge actually cache a QUERY, and what did the gateway team say when we asked.” For a shop that lives in the CDN and API-gateway layer, that is not a footnote. That is the interesting part. It is worth noting that one of the RFC’s three authors works at Cloudflare (Reschke et al., 2026), which tells you where the people who wrote it expect the hard problems to land.

What I would actually do on Monday

Use QUERY where you own both ends. Internal service to internal service, your own client to your own API, anywhere you control the caller and the infrastructure between them, adopt it now. You get safe, idempotent, retryable reads with a real body and no guilt.

At the public edge, treat it as progressive enhancement. Advertise support with Accept-Query, accept QUERY from callers who send it, and keep a POST path for everyone whose stack has not caught up, which today is most of them. If you want the caching win, design for the Content-Location handoff deliberately rather than assuming your existing cache will do the right thing, because it will not until someone teaches it to.

And the next time that meeting starts, you get to say the words I have wanted to say for years: the correct method exists, it is called QUERY, and the only open question is whether our infrastructure has heard of it yet. That is a much better argument to be having. This is, as it happens, the exact seam where Sakura spends its days, wiring HTTP semantics through the CDN and gateway layer so the correct answer on paper becomes the fast answer in production.

The old argument is settled. Long live the new argument.

References

Fielding, R., Nottingham, M. and Reschke, J. (2022) RFC 9110: HTTP Semantics. Internet Engineering Task Force. Available at: https://www.rfc-editor.org/rfc/rfc9110 (Accessed: 6 July 2026).

Jawad, A. (2026) HTTP finally gets a method it’s needed for decades: meet QUERY. Medium. Available at: https://medium.com/@anmjawad007/http-finally-gets-a-method-its-needed-for-decades-meet-query-bb1b77def9a3 (Accessed: 6 July 2026).

Reschke, J., Reddy, S., Davis, J. and Babich, A. (2008) RFC 5323: Web Distributed Authoring and Versioning (WebDAV) SEARCH. Internet Engineering Task Force. Available at: https://www.rfc-editor.org/rfc/rfc5323 (Accessed: 6 July 2026).

Reschke, J., Snell, J.M. and Bishop, M. (2026) RFC 10008: The HTTP QUERY Method. Internet Engineering Task Force. Available at: https://www.rfc-editor.org/rfc/rfc10008 (Accessed: 6 July 2026).