Hiya folks,
Quick PSA. If you design or consume APIs, and if you’re reading this blog you probably do, this one’s worth five minutes. Not an HTTP spec expert here, just something I stumbled on that seemed worth sharing.
The problem QUERY solves
Quick refresher if you’re new to this (no judgment, I had to look half of it up too). HTTP has “methods,” GET, POST, PUT, DELETE and so on, that tell a server what kind of request you’re making. Two of them matter here.
GET is the one everyone knows. Safe (doesn’t change anything), idempotent (run it twice, same result, no side effects). But everything has to fit in the URL. Big filter objects turn into unreadable query strings. Size limits aren’t consistent across proxies and servers. URLs get logged and bookmarked in ways request bodies don’t. Try passing a complex search filter with nested conditions through a URL and you’ll feel this pain fast.
POST fixes the size problem. You get a proper request body. But it throws away the safety guarantee. A POST might create a record, kick off a workflow, or just run a search. Nothing in the protocol tells a cache, proxy, or client “this one’s read-only, retry it freely.”
So the workaround for years, at least everywhere I’ve worked, has been simple: POST a search body and hope nothing downstream treats it as a mutation. It works. It’s just a bit of a lie about what the request actually is.
What RFC 10008 actually defines
The IETF HTTP Working Group closed that gap, apparently. RFC 10008, The HTTP QUERY Method, was published in June 2026 as a Proposed Standard. Authors: Julian Reschke (greenbytes), James Snell (Cloudflare), Mike Bishop (Akamai) — names I recognised from other HTTP spec work, though I’ll admit I had to go look that up too.
QUERY takes the body support of POST and pairs it with the safe, idempotent semantics of GET. Send a body. Every cache, proxy, and client in between knows it won’t change anything server-side, so it can be retried safely, at least in theory.
QUERY /users HTTP/1.1
Host: example.org
Content-Type: application/json
{ "role": "admin", "sort": "name", "page": 1 }Same shape as a search-by-POST request. Except now it’s declared safe and idempotent at the protocol level instead of buried in a docs page nobody reads.
A few extra details worth knowing. Accept-Query is a new response header letting a server advertise which content types it accepts on a QUERY, discoverable via a HEAD request. Failure semantics are spelled out too: missing media type gets a 400, unsupported media type gets a 415, a well-formed but unprocessable query gets a 422. And it’s cacheable and safely repeatable by design, same as GET, on paper anyway.
Pros and cons
Pros:
- Read-only gets enforced by the protocol, not a comment in your API docs
- Safe to retry automatically, useful on flaky networks and long-running dashboards
- Cacheable like GET, something POST-based search never got for free
- Complex filters live in a body instead of getting crammed into a URL
Cons:
- No major browser supports it natively yet, so this isn’t something you can rely on today
- Server and framework support is only just emerging
- Older proxies, some API gateways, and monitoring tools may not even recognise QUERY as a method until they’re updated
- One more read-ish verb to reason about alongside GET and POST, and teams still need to agree on when to actually use it
I don’t have a strong read on how fast this gets adopted, honestly. Standards like this often sit unused for years. This one’s got Cloudflare and Akamai as co-authors, which feels like a decent sign, but that’s a guess more than a prediction.
Why this matters for identity
Most identity APIs I’ve worked with are read-heavy, and most of those reads are more complex than a GET can comfortably express. Entitlement search across a large role model. Access review candidate filtering with multiple conditions and nested logic. Identity search on attribute-based criteria. Filter queries that outgrow a URL fast.
Right now most identity and governance platforms I’ve come across handle this the way everyone else does: POST a search body and hope nothing downstream treats it as a mutation. Caches can’t trust it. Retries aren’t automatically safe. Whether the endpoint is actually read-only lives in documentation, not the protocol.
QUERY looks like a better fit for this kind of endpoint, at least to me. An access review dashboard hammering the same filtered search repeatedly could benefit from safe retries and caching. A reporting endpoint pulling entitlement usage data sounds a lot like the large, structured, read-only case the RFC describes.
You can’t build against this in production today. But if you’re designing or reviewing identity APIs, might be worth knowing the shape of it before it turns up somewhere.
ProTip: worth a look at your own APIs, or the ones you integrate with, for POST endpoints that are secretly just reads with a complex filter attached. Those might be your QUERY candidates once tooling catches up, whenever that is.
I’ll keep an eye on this and update if anything changes. For now, know the name, know the shape, and don’t be too surprised when it turns up in a spec near you.
Catch ya in the next one.