🚀 The New HTTP QUERY Method: The First New HTTP Method in 16 Years
What if you could have the simplicity of GET with the flexibility of POST? That's exactly what the new HTTP QUERY method aims to deliver.
If you've built REST APIs, you've probably faced this situation before.
You need to fetch data from your server, so naturally, GET seems like the right choice. But then your filters become more complex. You need nested objects, multiple conditions, sorting, pagination, maybe even advanced search criteria. Suddenly, your URL starts looking like a puzzle.
GET /orders?status=paid&customer=Ravi&from=2026-01-01&to=2026-06-30&sort=-amount&page=2&include=products,shipping,payments
As the application grows, that URL only gets longer and harder to manage.
Most developers eventually switch to POST for search endpoints, even though they're only retrieving data.
For years, this has been one of the awkward compromises in REST API design.
That changes with the new QUERY HTTP method, standardized in RFC 10008 (June 2026).
Why Was QUERY Needed?
Let's understand the problem first.
Imagine you're building an e-commerce platform.
A user wants to search orders based on:
- Customer name
- Order status
- Date range
- Price range
- Multiple product categories
- Sort order
- Pagination
With GET, everything has to fit inside the URL.
GET /orders?customer=Ravi&status=paid&category=laptop&category=gaming&page=3&sort=-price
This works...
...until it doesn't.
As the filters become more advanced, URLs become difficult to read, difficult to encode correctly, and can even exceed practical length limits imposed by browsers, servers, or proxies.
Another downside is that query parameters often appear in logs, browser history, and analytics systems, making them less suitable for sensitive search criteria.
Clearly, developers needed a better solution.
Why Not Just Use POST?
This is exactly what many APIs do today.
POST /orders/search
Content-Type: application/json
{
"customer": "Ravi",
"status": "paid",
"categories": [
"Laptop",
"Gaming"
],
"price": {
"min": 500,
"max": 2000
},
"page": 3
}
The request body solves many problems.
It's clean.
It's readable.
It supports complex JSON.
So what's wrong?
The issue isn't technical.
It's semantic.
POST traditionally represents an operation that may change server state.
Searching for data doesn't.
Using POST for read-only operations has always been a compromise because HTTP infrastructure can't safely assume the request is cacheable or automatically retryable.
Meet QUERY
QUERY combines the strengths of both GET and POST.
Instead of placing filters in the URL, you send them inside the request body.
QUERY /orders
Content-Type: application/json
{
"customer": "Ravi",
"status": "paid",
"categories": [
"Laptop",
"Gaming"
],
"price": {
"min": 500,
"max": 2000
}
}
Unlike POST, QUERY is explicitly defined as a safe and idempotent method.
That means everyone involved—the client, server, proxy, and cache—knows that executing the request will not modify server data.
This makes QUERY a much better fit for complex searches.
What Does "Idempotent" Actually Mean?
You'll often hear this word when talking about HTTP methods.
An operation is idempotent if performing it multiple times has the same effect as performing it once.
For example:
GET /users/42
Calling this request one time or ten times returns the same user.
Now compare that to:
POST /users
Calling it twice could create two different users.
That's why POST isn't considered idempotent.
QUERY behaves like GET in this regard.
If the network connection drops halfway through the response, a client can safely retry the QUERY request without worrying about accidentally changing server data.
Why This Matters
The QUERY method brings several advantages:
✅ Supports complex request bodies
✅ Safe for read-only operations
✅ Idempotent
✅ Easier for caching systems to understand
✅ Better HTTP semantics
Instead of inventing custom search endpoints like:
POST /users/search
POST /orders/filter
POST /products/query
Applications can eventually expose cleaner APIs using QUERY.
A Practical Example
Imagine you're building an analytics dashboard.
Today's API might look like this:
POST /analytics/report
Request body:
{
"dateRange": {
"from": "2026-01-01",
"to": "2026-06-30"
},
"groupBy": "country",
"metrics": [
"sales",
"profit"
]
}
The request doesn't create anything.
It simply retrieves data.
QUERY expresses that intent much more clearly.
QUERY /analytics/report
Same body.
Better semantics.
What About Spring Boot and Other Frameworks?
If you're a Java developer like me, you've probably written endpoints such as:
@PostMapping("/search")
even though they're only returning data.
At the time of writing, most frameworks—including Spring Boot, Express, FastAPI, ASP.NET Core, and many API gateways—don't yet provide first-class support for QUERY because the standard is still very new.
As ecosystem support grows over the next few years, it will be interesting to see how frameworks adopt it.
Should You Use QUERY Today?
Probably not in production.
Although the method has now been standardized, widespread support is still limited.
Many HTTP clients, frameworks, reverse proxies, API gateways, and developer tools have yet to implement it.
For now, the common approach remains:
- Use GET for simple resource retrieval.
- Use POST when you need complex search bodies and QUERY isn't available.
- Keep an eye on framework support as the ecosystem evolves.
Final Thoughts
HTTP has remained remarkably stable over the years, and that's a good thing.
But there has always been a missing piece between GET and POST.
QUERY fills that gap by providing a standard way to perform complex, read-only requests without sacrificing HTTP semantics.
Will it replace GET?
No.
Will it replace POST?
Not entirely.
Instead, it gives developers a better tool for scenarios where neither GET nor POST feels quite right.
It may take a few years before QUERY becomes common in production APIs, but understanding it today will help you design better APIs tomorrow.
What do you think about the new QUERY method?
Would you use it once your favorite framework supports it? Let me know in the comments!
Thanks for reading! If you enjoyed this article, consider leaving a ❤️ and following me here on DEV Community for more content on Java, Spring Boot, backend engineering, and modern web technologies.
Top comments (0)