For more than two decades, developers have relied on GET and POST for almost every API request.
- Need to fetch data? Use GET.
- Need to send data? Use POST.
But modern applications have changed.
Today’s APIs often need to send complex search filters, nested objects, arrays, pagination rules, sorting options, permissions, and analytics queries. Using GET for these requests has become increasingly difficult.
To solve this problem, the IETF introduced the HTTP QUERY method (currently under standardization), a method specifically designed for complex read-only requests.
Let’s understand why it exists, how it compares with GET and POST, and why it could become an important part of future API development.
The Problem with GET
GET has always been the standard method for retrieving resources.
Example:
GET /products?category=electronics&page=2&sort=price
Simple and clean.
But imagine an advanced search.
{
"category": ["electronics", "gaming"],
"price": {
"min": 100,
"max": 1000
},
"brands": [
"Apple",
"Sony",
"Samsung"
],
"features": [
"Bluetooth",
"5G",
"OLED"
],
"sort": [
{
"field": "rating",
"direction": "desc"
}
]
}Representing this entire structure in a URL becomes messy.
GET /products?category=electronics,gaming&price[min]=100...
Problems include:
- Very long URLs
- Difficult to read
- Hard to maintain
- Browser URL length limits
- Proxy limitations
- Sensitive search parameters become visible
Why Developers Started Using POST for Searches
To avoid long URLs, many APIs began using POST.
Example:
POST /products/search
Body:
{
"category": ["electronics"],
"price": {
"min": 100,
"max": 1000
}
}This works perfectly.
However, it introduces another issue.
POST is intended for creating or processing resources.
Searching is a read-only operation.
Using POST for reads creates semantic confusion.
Enter HTTP QUERY
The new QUERY method combines the best parts of GET and POST.
Like GET:
- Read-only
- Safe operation
- Doesn’t modify server data
Like POST:
- Supports a request body
- Handles complex JSON
- No URL length limitations
Example:
QUERY /products
Content-Type: application/json
{
"category": ["electronics"],
"price": {
"min": 100,
"max": 1000
},
"sort": [
{
"field": "rating",
"direction": "desc"
}
]
}The request clearly communicates:
“I’m querying data, not creating anything.”
GET vs POST vs QUERY
Real-World Example
Suppose you’re building an e-commerce platform.
A user wants:
- Electronics
- Samsung or Sony
- Price below $1000
- In stock
- Rating above 4.5
- Sort by popularity
- Include seller information
- Return only selected fields
Using GET:
GET /products?category=electronics&brand=Samsung,Sony...
The URL quickly becomes hundreds of characters long.
Using POST:
POST /products/search
Works.
But POST implies some server-side processing or modification.
Using QUERY:
QUERY /products
Body:
{
"category": "electronics",
"brands": [
"Samsung",
"Sony"
],
"price": {
"max": 1000
},
"rating": {
"min": 4.5
},
"stock": true,
"sort": "popularity"
}Clear.
Readable.
RESTful.
Benefits of HTTP QUERY
1. Better API Design
The request clearly represents a query operation.
No more fake endpoints like:
POST /search
POST /filter
POST /find
2. Complex JSON Support
Nested objects become natural.
{
"location": {
"country": "India",
"city": "Delhi"
},
"skills": [
"React",
"Node.js",
"AWS"
]
}Impossible to represent cleanly with GET.
3. No URL Length Limits
URLs remain short.
Large filters stay inside the request body.
4. Easier Backend Validation
Frameworks already validate JSON bodies.
No need to manually parse dozens of query parameters.
5. Improved Readability
Developers can instantly understand what the API is doing.
Earlier Limitations
Before QUERY, developers had only two imperfect choices.
Option 1
Use GET.
Problems:
- URL too long
- Difficult encoding
- Browser limitations
Option 2
Use POST.
Problems:
- Wrong HTTP semantics
- Harder caching behavior
- Less intuitive API design
Neither option was ideal.
QUERY fills this gap.
Current Support
Since QUERY is still progressing through the IETF standardization process:
- Browsers do not yet expose it in HTML forms.
- Most backend frameworks don’t support it out of the box.
- Many API gateways and proxies need updates.
- Tooling and SDK support is still evolving.
Adoption will likely take time, just as PATCH required years to become widely supported.
When Should You Use QUERY?
Ideal scenarios include:
- Advanced search APIs
- Analytics dashboards
- Reporting systems
- Elasticsearch queries
- Product filtering
- Graph-like queries
- Business intelligence APIs
- Complex read-only operations
When Should You Continue Using GET?
GET is still the best choice when:
- Fetching a user profile
- Loading a blog post
- Getting product details
- Reading configuration
- Downloading files
Simple requests should remain GET requests.
Final Thoughts
HTTP has remained remarkably stable for decades, but the needs of modern applications continue to evolve.
As APIs grow more sophisticated, developers have increasingly used POST for read-only operations simply because GET cannot carry complex request bodies. The emerging HTTP QUERY method offers a cleaner alternative by preserving the semantics of a safe, read-only request while allowing rich JSON payloads.
Although it is still an evolving standard and not yet universally supported, QUERY represents an important step toward more expressive and maintainable APIs. If you’re designing REST APIs or building backend systems, it’s worth keeping an eye on this proposal — it could influence how complex data retrieval is implemented in the years ahead.
The future of HTTP isn’t about replacing GET or POST; it’s about giving developers the right tool for the right job.