Why it worked
The post uses a relatable hook comparing a new HTTP method to the highly anticipated GTA 6 release, generating curiosity. It then clearly explains a technical problem and presents a novel solution in a digestible, step-by-step format with code examples.
Summary
This post explains the new HTTP QUERY method, which addresses limitations of GET and POST requests for complex searches. It highlights how QUERY offers the body-carrying capability of POST with the safety and idempotency of GET.
On-screen text
HTTP's first
new method
in 16 years
SWIPE
We got a new HTTP
method before GTA 6.
Here's how it works...
Say you're building an
orders search with a
bunch of filters. Until
now, there were only
two ways to do it...
1) Using a GET request
You hit length limits with lots of
filters, and the query string gets
logged and stored in browser
history, so sensitive values leak.
GET /orders
?email=marco.rossi@gmail.com
&status=refunded
&payment_method=card
&from=2026-01-01
&to=2026-07-14
2) Using a POST request
The filters move into the body, so
nothing leaks. But POST is meant
for writes, so nothing can safely
cache or retry it.
POST /orders/search HTTP/1.1
Host: api.example.com
Content-Type: application/json
{
"email": "marco.rossi@gmail.com",
"status": "refunded",
"payment_method": "card",
"from": "2026-01-01",
"to": "2026-07-14"
}
This is the gap the new
QUERY method fills.
It carries a body like
POST, but it's safe and
idempotent like GET...
The new QUERY method
It handles big, complex filters the
way POST could, and the response
stays cacheable and safe to retry,
just like a GET request.
QUERY /orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
{
"email": "marco.rossi@gmail.com",
"status": "refunded",
"payment_method": "card",
"from": "2026-01-01",
"to": "2026-07-14"
}
Send this POST to
your backend friend!