GET vs. QUERY vs. POST: HTTP just changed the conversation For years, APIs have used two imperfec...GET vs. QUERY vs. POST: HTTP just changed the conversation For years, APIs have used two imperfec...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Steve's avatar
Qorpia logo
Steve Castillo
• Jul 18
GET vs. QUERY vs. POST: HTTP just changed the conversation
For years, APIs have used two imperfect approaches for complex searches:
- Put every filter in a GET URL.
- Send the filters in a POST body, even when no data is being modified.
In June 2026, the IETF published RFC 10008, officially introducing the HTTP QUERY method.
Its goal is simple: allow structured queries inside a request body while keeping the operation safe, idempotent, and potentially cacheable.
QUERY /products
Content-Type: application/json

{
  "category": "laptops",
  "brands": ["Dell", "Lenovo"],
  "price": {
    "min": 800,
    "max": 2000
  }
}
How do they compare?
GET
- Best for simple, read-only requests.
- Filters usually live in the URL.
- Safe, idempotent, and cache-friendly.
Ideal when URLs need to be shared or bookmarked.
GET /products?category=laptops&minPrice=800
QUERY
- Designed for complex, read-only queries.
- The query is sent in the request body.
- Safe, idempotent, and cacheable by definition.
- Better suited for nested filters, reports, analytics, and structured search.
QUERY /products
Content-Type: application/json

{ "category": "laptops", "minPrice": 800 }
POST
- Designed for processing data or performing actions.
- The payload is sent in the request body.
- It is not assumed to be safe or idempotent.
- Best for commands and operations that may change system state.
POST /orders
Content-Type: application/json

{ "productId": 42, "quantity": 1 }
The practical rule could be:
- Simple read? Use GET. - Complex read with a body? Consider QUERY. - State-changing operation? Use POST.
However, there is an important caveat: a published standard does not mean the entire ecosystem is ready.
Browsers allow custom methods through fetch, but cross-origin requests require a CORS preflight. OpenAPI 3.2 already supports query, while frameworks, proxies, CDNs, and client generators still need time to adapt.
NestJS, for example, does not yet provide RequestMethod.QUERY or a dedicated HTTP decorator. Spring can represent custom methods in its client APIs, but Spring MVC still lacks first-class annotation mapping for it.
QUERY is not here to replace GET or POST. It gives APIs a clearer way to say:
“This request has a body, but it is still read-only, repeatable, and cacheable.”
Would you adopt QUERY today, or wait until your framework supports it natively?
References: RFC 10008 · Fetch Standard · OpenAPI 3.2
And remember: good software starts with good decisions. See you in the next one.
programmingtechnewswebdevelopment
Post image
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started