HTTP Gets a QUERY Method After 30 Years
RFC 10008 proposes a formal QUERY HTTP method, which would let clients send a request body with GET-like semantics, meaning cacheable and idempotent. This solves a long-standing awkwardness: GET requests can't have bodies per spec, but complex search APIs need to send structured query parameters that don't fit in a URL. The workaround has always been POST, which technically isn't idempotent and can't be cached the same way.
The HN thread noted the obvious: URL length limits have been a known problem forever, and the workaround of abusing POST has been standard practice for decades. Some pushed back asking whether ETags on POST requests would accomplish the same thing. The RFC authors say no, because the semantic meaning matters for caches and intermediaries, not just the technical behavior.
The 'wait, we're past RFC 10000?' comment captured the quiet surprise that HTTP is still being actively developed and standardized at this level of detail. It's easy to treat HTTP as a solved problem.
So what?
If you're building search APIs or any endpoint that takes complex query parameters, the QUERY method will eventually let you design cleaner, cacheable interfaces without abusing POST. It's not something to block on now, but it's worth tracking so your API design doesn't paint you into a corner when client and server support arrives. More immediately, this is a good moment to audit whether your existing search endpoints are using POST in ways that hurt cacheability.