QUERY: the HTTP method we've been faking for 16 years

HTTP just got its first brand-new method since 2010. Meet QUERY, a GET with a body, or a POST that's finally honest about being read-only.

Every backend dev has hit this moment. You've got a search endpoint. The filters are getting spicy: nested facets, an array of tags, a sort order, a date range. You reach for GET, because searching is reading and reading is a GET, obviously.

Then your query object grows up, your URL crosses two thousand characters, some proxy three hops away quietly truncates it, and you spend an afternoon learning which piece of middleware hates you today.

So you give up and switch to POST. It works. But now you're lying. POST tells every cache, CDN, and proxy on the wire, "careful, this might change something," when all you did was ask a question. No caching for you.

We've been stuck choosing between a verb that can't carry luggage and a verb that sets off the alarm at every checkpoint. For sixteen years there was no third option.

Now there is.

Meet QUERY

In June 2026 the IETF published RFC 10008, standardizing a new HTTP method called QUERY. It's the first genuinely new standard HTTP method since PATCH landed back in 2010, which in web-standards time is roughly an ice age.

The pitch is almost annoyingly simple. QUERY takes the request body from POST and the good manners from GET:

• It carries a body, so your gnarly filter object goes where it belongs.
• It's safe: the server promises not to change state.
• It's idempotent: fire it twice, get the same result, no harm done.
• And because of those two promises, it's cacheable.

That last point is the quiet superpower. A cache can look at a QUERY, see that it's safe and idempotent, and reuse the response, something it could never responsibly do with a POST.

What it actually looks like

Nothing exotic. It's a request line you already know how to read, just with a new verb at the front and a body hanging off the bottom:

QUERY /products HTTP/1.1
Host: api.shop.example
Content-Type: application/json
Accept: application/json

{
  "filter": { "category": "boots", "inStock": true },
  "sort": "-price",
  "limit": 20
}

The Content-Type isn't decoration. It tells the server what language your query is written in. JSON here, but nothing stops a resource from speaking JSONPath, a SQL-ish dialect, or some format your team invented on a whiteboard. The URL identifies what you're querying; the body says how.

Notice the response header:

HTTP/1.1 200 OK
Accept-Query: application/json
Cache-Control: max-age=60, private

Accept-Query is the other new thing the RFC introduces. It lets a resource advertise which query formats it understands, the same way Accept-Post works for POST. Self-documenting endpoints, for free.

Wait, haven't we seen this before?

Kind of! If QUERY feels familiar, that's because its great-grandparent is the old WebDAV SEARCH method. The idea of "a read that carries a body" has been circling the standards world for two decades. It just never made it into the HTTP core vocabulary, not until the working group dusted it off, sanded down the rough edges, and gave it a name that says exactly what it does.

And honestly, we've all been simulating QUERY for years. Elasticsearch let you send a body with GET /_search (technically undefined behavior that half the tooling refuses to send) and also offered POST /_search for when that broke. That awkward dance, where you pick your poison and give up either the body or the caching, is precisely the gap QUERY fills.

The one gotcha: caching keys

Here's the detail that'll bite the unwary. When a cache stores a normal GET, the cache key is basically the URL. Two identical URLs, same cached response.

But two QUERY requests to the same URL can have completely different bodies. That's the whole point. So a compliant cache must fold the request body into the cache key. If your cache or CDN doesn't understand QUERY yet, it might key on the URL alone and cheerfully hand user B the results of user A's query. Fun bug. Do not ship it.

The RFC is explicit about this, but your infrastructure has to actually implement it. Which brings us to the part where I gently pump the brakes.

Should you rush this into production?

No. Love the enthusiasm, but no.

QUERY is a proposed standard, published in mid-2026. That means the spec is solid, but the ecosystem is still catching up:

• Browsers don't send QUERY from fetch() everywhere yet, and HTML <form> still only knows GET and POST.
• Plenty of proxies, WAFs, and API gateways drop or reject methods they don't recognize.
• Cache implementations that key QUERY correctly are the exception, not the rule today.

Support like this spreads in years, not weeks. PATCH was standardized in 2010 and still trips over the occasional stubborn gateway.

So treat QUERY the way you'd treat any shiny new protocol feature: understand it, design your API vocabulary with it in mind, maybe reach for it behind your own controlled infrastructure where you own the whole path. But keep that POST /search endpoint around for a while yet.

The takeaway

QUERY isn't flashy. It doesn't unlock anything you literally couldn't do before. What it does is end a sixteen-year-old compromise. It lets you say, right there in the protocol, "I'm asking a question, not changing anything, and here's my complicated question in the body." And for the first time, the caches and proxies on the wire can actually understand you.

It's a small verb with a big job: making read-only requests honest again.

Now if you'll excuse me, I have a few POST /search endpoints to feel guilty about.

---

Have you started experimenting with QUERY yet, or are you waiting for the ecosystem to catch up? Let me know in the comments.