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

1w ago 61 2

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?

2 Comments

Bharat Varshney

1w ago

For my opinion, GET was ideal for fetching data, but it came with limitations: Query parameters could become long and difficult to manage. Request bodies for GET are not consistently supported across clients, proxies, and servers. Complex filters didn't fit naturally into URLs. So many APIs started using POST for read operations. It worked, but it blurred the line between reading and modifying data. That's where HTTP QUERY comes in.

Ishan Dev Shukl

1w ago

Absolutely

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

2 Comments

Join the discussion