The web has relied on the same set of HTTP methods for decades: GET, POST, PUT, PATCH, and DELETE. While these methods have proven reliable, modern APIs are increasingly dealing with highly complex search requests that don't fit neatly into the traditional model.
A new proposal, known as QUERY, aims to address this limitation by introducing a dedicated HTTP method specifically designed for complex read-only queries.
Why GET Isn't Always Enough
The GET method is ideal for retrieving resources using simple URL parameters. However, it has several drawbacks when queries become more sophisticated:
URLs can become extremely long.
Nested filters are difficult to represent.
Complex JSON structures cannot be included in the request body.
Long URLs may exceed browser or server limits.
For example, searching a large product catalog with dozens of filters quickly becomes impractical using query parameters alone.
Why POST Isn't the Perfect Solution
Many developers solve this problem by using POST requests for searches.
While this works technically, POST was originally intended for operations that create or modify server-side state. Using POST for read-only searches introduces several disadvantages:
Caching becomes less efficient.
API semantics become less clear.
HTTP tooling cannot easily distinguish between read and write operations.
Monitoring and optimization become harder.
Enter the QUERY Method
The proposed QUERY HTTP method provides a clean solution.
Like GET, QUERY is intended for safe, read-only operations. Unlike GET, it allows clients to send a request body containing structured data, typically JSON.
Example:
QUERY /products HTTP/1.1
Content-Type: application/json
{
"category": "laptops",
"price": {
"min": 800,
"max": 2000
},
"brands": [
"Dell",
"Lenovo",
"Framework"
],
"sort": "price"
}
This approach makes complex filtering much easier while preserving the semantics of a read-only request.
Main Benefits
The QUERY method offers several advantages:
Cleaner API design.
Better support for complex filtering.
JSON request bodies.
Easier integration with modern applications.
Potential compatibility with caching mechanisms designed for safe requests.
Clear separation between reading and modifying data.
Potential Use Cases
QUERY could become particularly useful for:
E-commerce search engines
Analytics dashboards
Business intelligence platforms
Geographic Information Systems (GIS)
AI-powered search APIs
Graph-like querying without adopting GraphQL
Current Status
It's important to note that QUERY is not yet part of the official HTTP standard and browser, server, and proxy support is still evolving. Developers should verify compatibility before using it in production environments.
Nevertheless, the proposal reflects an important trend: modern web applications increasingly require expressive, structured, and efficient query mechanisms that traditional GET requests cannot easily provide.
As APIs continue to grow in complexity, HTTP itself must evolve. The proposed QUERY method is an elegant attempt to bridge the gap between the simplicity of GET and the flexibility of POST while preserving proper HTTP semantics.
Whether QUERY becomes a widely adopted standard remains to be seen, but it represents an exciting step toward more expressive and developer-friendly web APIs.