Search for a command to run...
The clean, body-backed middle ground between GET and POST has finally arrived.
No comments yet. Be the first to comment.
Create professional invoices with PDF and PNG export, built-in UPI payment QR codes, multiple workspaces, and complete local privacy. No signup required.
What is it, why it breaks, how to fix it, and when you actually need it in production.
Everything Developers Need to Know About Scrum, Kanban, and Surviving the Tech Industry
A practical guide to understanding the architectural decisions behind RabbitMQ and Kafka, not just their features.
Ashutosh Writes
111 posts
Ashutosh Writes is a tech-focused blog where practical learning connects with real-world development. It features clear, engaging articles on web development, Python, Java, artificial intelligence, and modern software engineering. From hands-on project tutorials and coding guides to AI concepts and development insights, the blog is designed to simplify complex topics and help developers learn, build, and grow at every stage of their journey.
Every developer building Web APIs eventually runs into the exact same architectural wall. You need to build a search feature, an analytics dashboard, or a complex reporting tool. The user selects a dozen active filters, specifies nested conditions, chooses sorting rules, and hits "Search."
Suddenly, your clean backend design faces an unpleasant choice. If you choose a traditional GET request, your URL balloons into an unreadable string of encoded text that risks crashing into web browser or server character limits. If you choose a POST request, you easily bypass the size limits by placing the filter data inside the request body, but you strip away the fundamental caching, safety, and retry guarantees that make HTTP work so beautifully.
For decades, we treated this tension as just another normal quirk of web development. We built complex workarounds like persisted queries or query hashing, pretending that using an action verb like POST to perform a read-only search was fine.
That compromise is no longer necessary. The Internet Engineering Task Force (IETF) officially introduced a new standard HTTP method designed to break this deadlock: QUERY (RFC 10008).
The QUERY method fills a massive gap in web architecture. It provides the heavy-lifting capability of a request body, while preserving the clean, read-only guarantees of a safe and idempotent fetch.
To understand why the QUERY method matters, we need to look at the practical limits of the options we have used for years.
When you learn REST API design, the rule is simple: if you are reading data, you use GET. This approach works flawlessly for simple lookups like /api/v1/users/42 or light filtering like /products?category=shoes&size=10. The parameters are right there in the URL string. They are easy to inspect, easy to bookmark, and perfectly suited for HTTP caching layers.
However, modern applications rarely stay that simple. Imagine you are building an advanced search engine or an enterprise reporting tool. Your user wants to filter products based on a highly complex query: they need items within a specific category, priced within a dynamic range, matching an array of tags, excluding clearance items, and sorted by a complex multi-column rule.
If you try to map that into a standard GET request, the URL starts looking like an encoded mess:
GET /products/search?filter%5Bcategory%5D=laptops&filter%5Bprice%5D%5Bmax%5D=1500&filter%5Btags%5D%5B0%5D=ssd&filter%5Btags%5D%5B1%5D=business&sort=price&order=desc HTTP/1.1
Host: query-demo-self.vercel.app
This approach presents four distinct architectural problems outlined in RFC 10008:
URL Length Limitations: While the HTTP specification doesn't enforce a hard limit on URL length, the real-world infrastructure handling your traffic does. Browsers, load balancers, corporate firewalls, and Content Delivery Networks (CDNs) often truncate or reject URLs that exceed a certain size—frequently capping out around 8,000 octets (bytes). If a user pastes a massive list of IDs into a search filter, a GET request will simply fail.
Privacy and Data Leakage: URLs are designed to be visible. Because query strings live directly inside the request target, they are automatically logged in plain text by web servers, stored in browser history files, and passed along in Referer headers to third-party scripts. If your search query contains sensitive filters—like an account number, a medical symptom, or personal data—that information leaks across your infrastructure.
Encoding Overhead: Expressing complex data structures inside a target URI is highly inefficient because of the overhead of percent-encoding brackets, spaces, and special characters, making network payloads harder to read and debug.
Resource Dilution: Encoding every single query combination directly into the request URI effectively casts every unique combination of query inputs as entirely distinct resources on the web, cluttering resource organization.
Faced with these limits, many developers ask a logical question: Why not just send a request body inside a standard GET request?
The short answer is that the web infrastructure treats GET bodies as having no defined semantic meaning. Because of this ambiguity, the ecosystem handles it completely inconsistently. Some proxy servers silently strip the body before passing the request forward. Other API gateways reject the request entirely, while some frameworks ignore the body. Altering how GET processes bodies today would break millions of legacy network systems.
Because GET with a body is unusable in the wild, the industry settled on an alternative workaround: using POST for complex searches.
When you use POST, all your complex filters travel cleanly inside the request body. You can send a beautifully structured JSON payload of any size, avoiding URL length limits and keeping sensitive terms out of system access logs.
POST /products/search HTTP/1.1
Host: query-demo-self.vercel.app
Content-Type: application/json
{
"category": "Laptops",
"price": { "max": 1500 },
"tags": ["ssd", "business"],
"sort": { "field": "price", "order": "desc" }
}
This works around the immediate structural limits, but it introduces a major flaw into your API's network behavior: POST is semantically unsafe and non-idempotent.
In the language of HTTP, a method is considered safe if it does not change the state of the resource on the server. A method is idempotent if executing it multiple times produces the identical result and state as executing it exactly once.
Because POST is designed for state-altering actions, like creating a new database record or processing a credit card payment, network intermediaries must assume that every POST request changes something on your server. This structural assumption breaks two core performance optimizations:
Caches Are Bypassed: Because a POST request is assumed to modify state, edge networks, CDNs, and browser caches will not cache the response by default. If a thousand users execute the exact same complex dashboard query within a minute, your origin server must compute that identical database search a thousand times.
Automatic Retries Are Blocked: If a network connection drops mid-request while a browser is sending a POST request, the browser cannot safely retry it automatically. Doing so might cause a double-charge or a duplicate record. The browser is forced to display a warning to the user, even if the backend endpoint was completely read-only.
The QUERY method defined in RFC 10008 directly resolves this tension. It serves as a semantic hybrid: it provides the robust request body capability of a POST, while strictly maintaining the safe, idempotent, and cacheable contracts of a GET.
When an endpoint uses QUERY, the protocol guarantees to every proxy, browser, and CDN along the route that the operation is entirely read-only. If a connection drops, your client library can seamlessly replay the request without risk. If an edge proxy sees identical query criteria come through a second time, it can serve a cached response immediately without waking up your origin database.
To see how this works in practice, let's look at a raw HTTP representation of a QUERY request alongside its response.
QUERY /products/search HTTP/1.1
Host: query-demo-self.vercel.app
Content-Type: application/json
Accept: application/json
Accept-Query: application/json
{
"category": "Laptops",
"brands": ["TechNova"],
"price": { "min": 500, "max": 1500 }
}
Unlike a classic GET, the QUERY method requires a Content-Type header. The specification explicitly dictates that if a client sends a QUERY request without a Content-Type, or if the header doesn't match the format of the body, the server MUST fail the request.
Notice the Accept-Query header. This allows the server to advertise exactly which query formats it knows how to parse for that endpoint—whether that is JSON, SQL, or a custom format.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=3600
Content-Location: /products/search/results/a1b2c3d4
Location: /products/search/stored-queries/42
{
"count": 2,
"query": {
"brands": ["TechNova"],
"category": "Laptops",
"price": { "max": 1500, "min": 500 }
},
"results": [
{
"id": 1,
"name": "UltraBook Pro 14",
"category": "Laptops",
"brand": "TechNova",
"price": 1299,
"rating": 4.8,
"stock": 32,
"discount": 15,
"available": true,
"tags": ["ssd", "lightweight", "business"],
"specs": { "cpu": "Intel Core Ultra 7", "ram": 32, "storage": 1024, "color": "Silver" }
},
{
"id": 3,
"name": "OfficeBook Air",
"category": "Laptops",
"brand": "TechNova",
"price": 799,
"rating": 4.3,
"stock": 50,
"discount": 20,
"available": true,
"tags": ["office", "budget"],
"specs": { "cpu": "Intel Core i5", "ram": 16, "storage": 512, "color": "Gray" }
}
]
}
The server processes the request payload, runs the search logic, and returns a standard 200 OK status with the data array.
The inclusion of the Content-Location and Location headers are incredibly powerful features of the specification:
Content-Location: Provides a direct URL pointing to a resource representing these specific results. A client can perform a standard GET request directly on that URL later to fetch the same snapshot.
Location: Points to the equivalent resource representing the query itself. A client can send a GET request to this URI to repeat the same search operation later without resending the large query body.
Let's look at how to implement and use the QUERY method using modern development tools.
You can test a QUERY endpoint directly from your terminal using standard cURL. We explicitly set the method to QUERY, provide the mandatory content headers, and pass our payload using the data flag.
curl -X QUERY https://query-demo-self.vercel.app/products/search \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{"category": "Laptops", "tags": ["gaming"]}'
Why this approach is useful: Because QUERY is officially registered in the IANA HTTP methods registry, modern command-line utilities and network tools handle it natively without needing custom transport hacks.
Modern web browsers allow you to pass arbitrary method names into the standard Fetch API. Here is how you can issue a QUERY request from client-side code:
async function searchProducts() {
const queryPayload = {
category: 'Laptops',
price: { min: 1000 },
sort: { field: 'price', order: 'desc' }
};
try {
const response = await fetch('https://query-demo-self.vercel.app/products/search', {
method: 'QUERY',
headers: {
'Content-Type': 'application/json',
'Accept': 'application/json'
},
body: JSON.stringify(queryPayload)
});
if (!response.ok) {
throw new Error(`HTTP error: ${response.status}`);
}
const data = await response.json();
console.log(`Found ${data.count} items:`, data.results);
return data;
} catch (error) {
console.error('Failed to execute search:', error);
}
}
This script looks almost identical to a standard POST implementation. However, behind the scenes, the browser knows that this request is safe and idempotent. If the network drops while waiting for the response, the underlying network engine can automatically handle retrying the operation safely.
Choosing the right tool for the job becomes much easier when we contrast the three methods side by side:
Architectural Property | GET | POST | QUERY |
Request Body Allowed | No (Undefined Semantics) | Yes | Yes |
Safe (Read-Only) | Yes | Potentially No | Yes |
Idempotent (Safe to Retry) | Yes | Potentially No | Yes |
Default Cacheable | Yes | No (Only future GET/HEAD) | Yes (Requires Body-Aware Keying) |
Data Payload Location | URL Query String | Request Body | Request Body |
Primary Use Case | Simple, short resource reads | Resource creation & mutation | Complex, large, or private reads |
While RFC 10008 represents a massive leap forward for clean API design, deploying it in production requires an honest look at the current state of network infrastructure. Because it is a newer standard, adoption is an evolving process across the web ecosystem.
Traditional caching proxies and CDNs use the request URL as the unique identifier—the "cache key"—to look up a stored response. For QUERY, this model breaks down completely. Two requests to /products/search could contain entirely different JSON filtering bodies, meaning they require completely different responses.
For QUERY caching to work safely, edge proxies must update their caching engines to fold the request body into the cache key calculation. While backend frameworks and language ecosystems have moved quickly to add native QUERY support, many edge networks and CDNs are still updating their systems to handle body-aware caching at scale.
Older Web Application Firewalls (WAFs) and load balancers operate on strict allowlists of classic HTTP verbs (GET, POST, PUT, DELETE). When an unconfigured security gateway encounters a QUERY request, it might react unpredictably—either blocking the traffic outright as a potential exploit attempt, or failing to inspect the body because it treats it like a standard GET.
Additionally, a QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will automatically require a "preflight" OPTIONS request, as QUERY does not belong to the basic set of CORS-safelisted methods.
If you want to start integrating the QUERY method into your current systems, use these design strategies to ensure a smooth transition:
Don't Replace Simple GETs: If a request fits cleanly within a standard URL without hitting size limits or exposing sensitive data, leave it as a GET. QUERY is designed to solve the limits of complex parameters, not to deprecate standard endpoint paths.
Leverage Discovery Methods: Use the OPTIONS method to return an Allow: GET, QUERY, OPTIONS, HEAD header, cleanly signaling to clients that the resource supports the new verb.
Handle Content Negotiation Failures Gracefully: Follow the RFC guidelines for client errors. If a query syntax is correct but points to a non-existent field or table, return a 422 Unprocessable Content status code. If the media type itself isn't supported, return a 415 Unsupported Media Type along with the Accept-Query header.
Validate the Content-Type Early: Always place a validation guard at the top of your route handlers. If an incoming QUERY request omits the Content-Type header, reject it immediately with a 400 Bad Request or 415 status code to stay aligned with the official specification rules.
The introduction of the QUERY method solves a structural compromise that engineers have accepted for decades. By merging the data payload flexibility of a request body with the strict safety and idempotency rules of a read operation, it removes the need to misuse POST for complex searches.
While full integration across every browser, WAF, and CDN proxy will take time, the establishment of RFC 10008 gives developers a standardized foundation to build cleaner, more predictable, and more efficient APIs.