The new HTTP method : QUERY

You work with REST APIs? You know GET, POST, PUT, DELETE...

But did you know that a new HTTP method was standardized in June 2026? It's called QUERY and it solves a problem developers have been working around for 16 years.

It's the first new standard HTTP method since PATCH (2010). Yes, you read that right: 16 years without major innovation in HTTP verbs.

The GET Method Problem

You want to create an endpoint to retrieve order information from your backend and add filters. You use a GET method for this endpoint because you're retrieving a resource and it’s the REST standards.

You add different parameters to the URL to filter results and return only orders that match your search:

GET /orders?select=surname,givenname,email&limit=10&match="email=*@example.*"

Problems:

• URLs have size limits (often 8000 characters max)
• Parameters are visible in logs (security issue)
• Impossible to make complex queries (advanced filters, SQL queries, JSONPath)
• Complex to encode correctly

What About Using POST instead?

To address the different problems with GET requests, you might turn to a POST request:

POST /orders HTTP/1.1
Host: api.example.org
Content-Type: application/x-www-form-urlencoded

select=surname,givenname,email&limit=10&match="email=*@example.*"

Problems:

• POST is not idempotent → if the network drops, you can't safely replay the request
• No standard HTTP caching
• Proxies don't know if it's safe to reject/retry
• Each framework implements its own "safe POST" system

The Solution: QUERY

QUERY gives you the best of both worlds:

QUERY /orders HTTP/1.1
Host: api.example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json

select=surname,givenname,email&limit=10&match="email=*@example.*"

Advantages:

• No URL size limit – The request body can contain SQL queries, JSONPath, or complex filters of unlimited size
• Idempotent – Execute the request 10 times = execute it once

What is Idempotence?

An operation is idempotent if calling it multiple times produces the same result as calling it once.

Concrete examples:

• ✅ GET /users/123 (idempotent) → 1 call = 10 calls = same data
• ✅ QUERY /users (idempotent) → replaying = same result
• ❌ POST /users (NOT idempotent) → 1 call creates 1 user, 2 calls create 2 users

Why is this crucial? If the network drops, you can safely replay without creating duplicates or corruption.

• Cacheable – Proxies, CDNs, browsers can cache the response (like GET)
• Request body – Send complex data in the body (like POST), not in the URL
• Safe – Never modifies server state (read-only)
• Safely replayable – If the network drops, you can replay the request with confidence
• URI for the request – The server can create a permanent URL to replay the same request

URI for the Request vs. URI for the Result

With classic POST (URI of result):

POST /orders → 200 OK

Content-Location: /results/xyz789

With QUERY (URI of the request):

QUERY /orders → 200 OK

Location: /saved-queries/42

The magic: Replaying /saved-queries/42 re-executes the same SQL/JSONPath query with updated data.

Concretely:

# Later...

GET /saved-queries/42

# → The server re-executes the original SQL query

# → You get fresh results

What's it useful for:

• Share a query (send the link to a colleague)
• Bookmark a search
• Cache the query (not just the results)
• Replay periodically without resending the body each time

Thanks to QUERY, we finally have functional HTTP caching for complex requests. Proxies, CDNs, and browsers can now cache requests with a body. This is huge for performance.

We also get an evolution in REST API design. Instead of:

GET /api/users/active
GET /api/users/inactive
GET /api/users/premium

You now have:

QUERY /api/users

With a single endpoint, it's easier to maintain, secure, and monitor.

Summary: GET vs POST vs QUERY

Feature	GET	POST	QUERY
Safe	✅ Yes	❌ No	✅ Yes
Idempotent	✅ Yes	❌ No	✅ Yes
Body allowed	❌ No	✅ Yes	✅ Yes
Cacheable	✅ Yes	⚠️ Complex	✅ Yes
Safely replayable	✅ Yes	❌ Risky	✅ Yes
URI for the request	✅ By default	❌ No	✅ Optional

---

Conclusion

QUERY finally gives us a solution for executing complex requests. It's a "small" change with a big impact. This new method solves a real problem that developers have been working around for years.

Moreover, this method was just standardized recently (June 2026), so it will take a while before it's truly adopted.

⚠️ Deployment Status

• ✅ Standardized: RFC 10008 (June 2026)
• ⏳ Implementation: Very few servers/clients support it yet
• 🚀 Timeline for adoption: Probably 2027-2028

Before using it in production, wait for implementations to become more widespread. For now, it's mainly important to understand the concept and keep it in mind for your future API architecture.

---

Next Step: QUERY in Practice

This article covers the theory and key concepts of QUERY. But how do you use it practically?

In a future article, I'll explore practical implementation of QUERY with a REST API, showing how to build a REST API that supports this new HTTP method and how to integrate it into a real-world architecture.

Stay tuned! 🚀