HTTP GET vs POST Dilemma

The dilemma every API designer has hit

If you've built a search endpoint with more than two or three filters, you've run into this trade-off:

  • GET is the semantically correct choice for a read-only operation. It's safe, idempotent, and cacheable. But query parameters live in the URL, and URLs have practical limits. RFC 9110 only recommends a floor of 8000 octets, and that's before you account for uncoordinated proxies and gateways along the way that may impose their own, undocumented limits. Nested JSON filters, large ID lists, and geospatial queries don't encode into a URI-safe string cleanly.
  • POST solves the body problem, but it tells every cache, proxy, and gateway in the path "this request might change state" which isn't true for a search. You lose caching, you lose safe-retry semantics, and you're lying to the protocol.

Most teams have picked POST and lived with the semantic mismatch. It works, but it's always been a workaround.

RFC 10008: a method built for exactly this gap

On June 15, 2026, the IETF published RFC 10008 The HTTP QUERY Method as a Standards Track Proposed Standard. It's authored by Julian Reschke (greenbytes), James M. Snell (Cloudflare), and Mike Bishop (Akamai), and it's the first genuinely new HTTP method since PATCH landed as RFC 5789 back in 2010. That's a 16-year gap.

QUERY is defined to be:

  • Safe: the client does not request or expect any state change on the server, the same guarantee GET makes.
  • Idempotent: repeating the same QUERY produces the same result, so clients and intermediaries can safely retry after a timeout or transient failure.
  • Body-carrying: unlike GET, the request content goes in the message body, not the URL.
  • Cacheable, but with a catch: the cache key must be derived from the full request, including the body, not just the URI. Get this wrong and you open the door to cache poisoning or cache deception.

What it looks like

Instead of forcing a filter into a URL:

GET /products?category=laptops&brand=Lenovo&priceMin=1000&priceMax=2500&features=32GB-RAM,OLED

you send:

QUERY /products
Content-Type: application/json

{
  "category": "laptops",
  "brand": "Lenovo",
  "price": { "min": 1000, "max": 2500 },
  "features": ["32GB RAM", "OLED"]
}

The intent is now explicit at the protocol level, not just documented in your API reference.

The details most summaries skip

A few mechanics in the RFC are worth knowing before you touch it in production:

Accept-Query header. A server can advertise which query formats it accepts:

Accept-Query: application/x-www-form-urlencoded, application/json

Clients can send OPTIONS or HEAD first to discover QUERY support and accepted formats before committing to a full request.

Content-Location vs. Location on the response. These serve two different purposes:

HTTP/1.1 200 OK
Content-Location: /contacts/stored-results/17
Location: /contacts/stored-queries/42

Content-Location lets the client issue a later GET to re-fetch the same result. Location lets it repeat the same query without resending the body. It's a small distinction, but it changes how you design result pagination and saved searches.

No CORS safelist. QUERY is not one of the CORS-safelisted methods (unlike simple GET/POST requests). Browser JavaScript calling a QUERY endpoint cross-origin will trigger a preflight OPTIONS request. If you're building a public API consumed from the browser, factor that into your CORS configuration now.

Adoption, honestly, as of July 2026

The RFC is barely a month old, so treat this as a snapshot, not a green light:

  • Node.js has been able to parse the QUERY method at the HTTP layer since early 2024, well ahead of standardization.
  • OpenAPI 3.2 already documents QUERY as a valid operation.
  • Spring is close but hadn't shipped support as of this writing.
  • Browsers are still evaluating fetch/XHR support.
  • Nginx and Apache will pass QUERY requests through at the transport level, but anything that allowlists methods, limit_except blocks, WAF rules, API gateway policies, CSRF middleware, was almost certainly written before June 2026 and won't recognize QUERY unless you add it explicitly.

That last point is the real bottleneck. The protocol doesn't need permission to carry a new method token. HTTP has never had a fixed method list. The friction is entirely in the layers built on top: routers, security policies, and caches that assume the usual five or six verbs.

Should you use it yet?

QUERY doesn't replace POST /search endpoints, and it doesn't need to. A sensible rollout looks like this:

  1. Keep your existing POST-based search endpoint working.
  2. Add a QUERY endpoint alongside it, advertised via Accept-Query.
  3. Let clients migrate as their tooling, SDKs, frameworks, and browsers catch up.
  4. Audit your WAF, gateway, and cache configuration for explicit QUERY handling before you rely on it as the only path to an endpoint.

For internal, server-to-server APIs where you control both ends, especially anything already running on Node.js, there's very little reason to wait. For public, browser-facing APIs, it's worth watching rather than shipping today.

Either way, HTTP just got a little more honest. GET means retrieval. POST means state change. QUERY means: I need to read something complicated, and I shouldn't have to lie about it to do it.

References