A look at HTTP's new QUERY method

What's wrong with GET and POST?

Traditional methods for managing information have significant problems for today's workloads. Enterprises commonly use these methods to retrieve data.

• GET. Simple, read-oriented queries with parameters in the URL.
• POST. Complex queries whose inputs are too large or cumbersome for a URL.

However, these methods have operational consequences. Long or highly encoded URLs can encounter size and interoperability constraints across proxies, gateways and other intermediaries. Furthermore, query information in URLs is more likely to surface in logs, browser history, bookmarks and other systems. In particular, using POST for read-only queries obscures the intended semantics and can limit the behavior of caches and automated retry mechanisms.

These consequences go beyond protocol design. They affect service reliability, incident recovery, data exposure, auditability and operational cost.

What is the new HTTP QUERY method?

As defined in RFC 10008: The HTTP QUERY Method, a QUERY is a request that asks a target resource to perform a query using content in the request body in a safe and idempotent way. In this context, safe and idempotent have specific meanings:

• Safe. The request is intended for retrieval/querying, not changing server state.
• Idempotent. Repeating the same request does not create additional state changes, making automated repetition safer.

The key distinction is that QUERY combines the body-based input of POST with the safe, idempotent semantics of GET. QUERY also supports caching.

QUERY vs GET and POST: The strategic difference

The strategic benefit isn't that QUERY makes APIs inherently faster or more secure. It gives organizations more precise control for complex read operations.

GET, POST and QUERY serve different purposes. GET is best for straightforward retrieval, QUERY for complex read-only queries and POST for when operations might create or change state. The distinction carries beyond API design to offer three practical advantages:

• Reliability. Due to its idempotent nature, QUERY provides a clearer basis for retry and recovery strategies when networks, gateways or downstream services fail.
• Observability. The dedicated QUERY method is differentiated in log files containing POST results, providing clarity for monitoring, classification and API governance.
• Compliance and governance. QUERY carries search criteria in the request body, reducing unnecessary exposure of information.

Note that implementing QUERY is a targeted modernization task, not an enterprise-wide migration project. It gives complex read operations their own explicit method, potentially reducing operational ambiguity and risk without requiring organizations to replace APIs that already work well.

Developer use cases

Developers and engineers can get the most value from the QUERY method in specific use cases, such as:

• Complex search or filter APIs.
• Analytics and reporting queries.
• APIs accepting structured query languages.
• Requests that routinely approach URI-size or encoding constraints.

Note that API gateways, WAFs, proxies, SDKs, observability platforms and application frameworks must recognize and correctly pass the new QUERY method. Watch for vendor updates.

Deployment options

Using QUERY entails specific advantages and trade-offs. For most organizations, integration is probably worthwhile for future applications. Some companies will want to retool existing APIs to add QUERY.

Option A: Retain existing GET/POST use

• Advantage: Lowest immediate friction.
• Trade-off: Appropriate when current APIs are reliable and query inputs are simple.

Option B: Introduce QUERY selectively

• Advantage: Best balance of risk and modernization.
• Trade-off: Add QUERY for new or high-value complex-query endpoints while retaining existing configurations.

Option C: Broad API migration (probably unnecessary for most organizations)

• Advantages: Potential long-term consistency.
• Trade-offs: Possible higher compatibility, testing and infrastructure risk.

Turn QUERY into a targeted risk-reduction initiative

QUERY fills a specific gap between GET and POST, so its use is situational. IT leaders should assess QUERY-ready use cases during the next API governance cycle. The results of that assessment will guide the next steps.

• Begin with selective adoption, not a wholesale rewrite.
• Create an API-method policy defining when teams should use GET, QUERY and POST.
• Identify a small number of complex read/query endpoints as pilots.
• Confirm compatibility with gateway, WAF, proxy, logging, monitoring, caching and security tools.
• Measure retry success, latency, error rates, observability coverage and sensitive data exposure.

Start today with one high-level question: Which existing APIs would be safer, more observable and easier to operate if complex queries had an explicit, idempotent HTTP method?

Damon Garn owns Cogspinner Coaction and provides freelance IT writing and editing services. He has written multiple CompTIA study guides, including the Linux+, Cloud Essentials+ and Server+ guides and contributes extensively to Informa TechTarget, The New Stack and CompTIA Blogs.