As backend developers, we've all encountered this dilemma.
You need to build a search endpoint that accepts multiple filters:
- Category
- Brand
- Price Range
- Rating
- Availability
- Location
The obvious choice is GET.
But as the filters grow, so do the problems.
The Problem with GET
A typical GET request looks like this:
```http id="wxb9s5"
GET /products?category=laptop&brand=dell&minPrice=500&maxPrice=1000
This works well for simple requests.
However, complex search APIs often require:
* Nested objects
* Arrays
* Dozens of filters
* Structured request payloads
Eventually, URLs become difficult to read and maintain.
---
## The Common Workaround
Most developers switch to **POST**.
```http id="8kl8pv"
POST /products/search
Content-Type: application/json
{
"category": "Laptop",
"brands": ["Dell", "HP"],
"price": {
"min": 500,
"max": 1000
},
"rating": 4
}
Technically, this works.
Semantically, though, it isn't ideal.
The request isn't creating or modifying anything.
It's simply retrieving data.
The Proposed Solution: QUERY
The proposed HTTP QUERY method is designed specifically for read-only operations that require a request body.
Example:
```http id="i1g0v0"
QUERY /products
Content-Type: application/json
{
"category": "Laptop",
"brands": ["Dell", "HP"],
"price": {
"min": 500,
"max": 1000
},
"rating": 4
}
This allows APIs to express their intent more clearly while keeping request payloads clean and structured.
---
## GET vs POST vs QUERY
| Feature | GET | POST | QUERY |
| ---------------- | :-: | :--: | :---: |
| Retrieve Data | ✅ | ✅ | ✅ |
| Request Body | ❌ | ✅ | ✅ |
| Safe (Read-only) | ✅ | ❌ | ✅ |
| Complex Filters | ⚠️ | ✅ | ✅ |
| Clear Semantics | ✅ | ❌ | ✅ |
---
## Where QUERY Makes Sense
The proposed method is a natural fit for:
* Advanced search endpoints
* Analytics APIs
* Reporting systems
* Enterprise filtering
* Graph-style queries
* Large read-only request payloads
---
## Things to Keep in Mind
At the time of writing, **`QUERY` is still a proposal** and is **not yet widely supported** by browsers, servers, frameworks, or API gateways.
For now, POST remains the practical choice for many complex search APIs.
Still, it's an interesting evolution of HTTP and one worth following.
---
## Final Thoughts
One thing I appreciate about the proposed `QUERY` method is that it focuses on **clarity**.
Good APIs don't just work—they communicate intent.
By separating "read with a body" from "modify data," `QUERY` has the potential to make REST APIs easier to understand and maintain.
Whether it becomes widely adopted or not, it's a fascinating discussion for backend engineers.
**What do you think?**
If your framework supported `QUERY` today, would you use it instead of POST for complex search endpoints?
I'd love to hear your thoughts in the comments.
Top comments (0)