HTTP QUERY: The New Method That Ends the GET-vs-POST Debate (RFC 10008)

Every backend developer has stood at this fork in the road.

You're building a search endpoint. The filter payload is big — nested filters, arrays, sort rules, pagination. And you have to pick a method:

• GET? It's the correct choice semantically. Safe, cacheable, read-only. But your query won't fit in the URL.
• POST? The body fits fine. But now you're lying — POST says "I'm changing something," and you're just reading data.

For about 20 years, we picked one and quietly felt wrong about it.

Last month, the IETF finally settled it. RFC 10008 — The HTTP QUERY Method was published as a Proposed Standard in June 2026.

Let's look at why the old options were never quite right, and what QUERY actually fixes.

Option 1: GET — safe, but it doesn't scale

GET /search?q=phones&filter=inStock&sort=price&page=3

// safe + cacheable ✅
// but... 414 URI Too Long ❌

GET is semantically perfect for search — it's safe (no side effects) and cacheable. The problem is purely mechanical: URLs have length limits. Browsers cap them, servers cap them, proxies and CDNs cap them. Once your filter object gets complex — an array of categories, a price range, nested boolean logic — you blow past those limits and start getting 414 URI Too Long.

You can URL-encode a giant JSON blob into a query string, but at that point you're fighting the tool.

Option 2: POST — it fits, but it lies
POST /search
Content-Type: application/json

{ "filter": "inStock", "sort": "price" }

// body fits ✅
// but POST means "I'm changing data" — a lie ❌

So most of us reach for POST. The body holds any payload you want. Done, right?

Not quite. POST is defined as neither safe nor idempotent — it signals that the request changes server state. But a search is read-only. That mismatch has real consequences:

Caches won't cache it (POST responses generally aren't cacheable).
Clients and proxies won't safely retry it on a network blip, because a retried POST could duplicate a side effect that, in your case, doesn't even exist.
Anyone reading your API can't tell a "search" POST from a "create order" POST without extra docs.
POST works. It just describes the wrong thing.

**The fix: QUERY**
QUERY /search
Content-Type: application/json

{ "filter": "inStock", "sort": "price" }

// safe + idempotent like GET ✅
// carries a request body like POST ✅

QUERY is exactly the method that was missing. From RFC 10008, a QUERY request asks the server to process the enclosed content in a safe and idempotent manner and return the result.

In practice, that means:

✅ Safe & idempotent, like GET — so it can be retried automatically without fear of side effects.
✅ Carries a request body, like POST — so your complex filters live in a proper JSON payload, not a fragile URL.
✅ Purpose-built for read-only data APIs — search, reporting, GraphQL-style queries, anything where "read a lot with a big query" is the shape.
It's the best of both, and it took a while — roughly 11 years from the first draft to a published standard.

Is it usable yet?

Sooner than you'd think:

Node.js has parsed the QUERY method natively since early 2024.
OpenAPI 3.2 can document QUERY operations.
Framework and tooling support (routers, client libraries, caches, WAFs) is still catching up — so you'll want to check your whole request path before shipping it to production.

So, should you switch?

For brand-new read-heavy APIs, QUERY is worth designing around now — with a POST fallback while the ecosystem matures. For entrenched POST /search endpoints, there's no rush, but it's finally a first-class, standardized answer instead of a compromise.

The "should this be GET or POST?" argument in code review? After 20 years, it finally has a real third option.

I'm Husnain Izhar, a Software Architect. I write about backend, APIs, and the practical side of building systems. If this was useful, follow me here — and I'd love to hear whether you're planning to reach for QUERY.