We Had GET and POST. So Why Did HTTP Need QUERY?

For years, developers faced an awkward compromise:

• GET was perfect for read operations—but request bodies were either unsupported or ignored.
• POST accepted complex payloads—but semantically implied an operation beyond simply retrieving data.

The result?

Countless APIs ended up exposing endpoints like:

POST /search



…even when they never modified a single byte of data.

With the standardization of HTTP QUERY (RFC 10008), that gap finally has an official solution.

But here’s the discussion I’d like to have.

Did we really need a new HTTP method?

Or are we solving a problem that modern APIs had already learned to live with?

From a testing perspective, QUERY opens interesting questions around:

• Caching strategies
• Idempotency
• API contracts
• Tooling support
• Backward compatibility
• REST semantics
• API gateways and proxies

Most API testing tools, frameworks, SDKs, and gateways have spent years optimizing around GET, POST, PUT, PATCH, and DELETE.

Will QUERY become another everyday HTTP verb…

Or will it join methods like TRACE and CONNECT that most developers rarely touch?