HTTP has a new method. RFC 10008, published by the IETF as a Proposed Standard in June 2026, defines QUERY — a method that's safe and idempotent like GET, but carries a request body like POST.
If you've ever encoded a huge filter object into a query string because GET couldn't carry a body, or used POST for a read-only search and lost cacheability in the process, QUERY closes that gap.
This post is a practical breakdown of how to test it — manually, with Postman, with automation, and with AI in the loop.
TL;DR on the Spec
Safe + idempotent — same guarantees as GET. Clients and proxies can retry it freely.
Has a body — same shape as POST. No more 8000-octet URL limits (RFC 9110's recommended cap) for complex queries.
Cacheable, but the cache key includes the body, not just the URL. This is the part most infra hasn't caught up to.
Not CORS-safelisted — browser calls to QUERY always trigger a preflight OPTIONS, same as PUT/DELETE.
New Accept-Query header — lets a resource advertise supported query formats, e.g.:
Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"
Now, testing.
1. Manual Testing
Before any tooling, walk through these by hand:
Method support: Does the endpoint even accept QUERY? Expect 405 Method Not Allowed on a lot of stacks right now — frameworks, gateways, and WAFs are still catching up.
Idempotency: Fire the identical request 5-10 times manually. No side effects, no state changes, same result every time.
Body edge cases: empty body, malformed JSON, oversized payload, wrong Content-Type. Confirm you get 400/415 where expected, not a silent 200.
Discovery: Send OPTIONS or HEAD and check whether Allow: QUERY and Accept-Query show up.
Caching: Repeat the same QUERY through your CDN/proxy — check for cache hits. Then vary the body slightly and confirm the cache key changes accordingly (mismatches here = cache poisoning risk).
CORS preflight: From a browser console, confirm an OPTIONS preflight actually fires before the QUERY request.
2. API Testing with Postman
Postman doesn't have a built-in QUERY button yet, but it's easy to add:
Method dropdown → "Custom method" → type QUERY.
Set the body (raw JSON, or whatever your API expects) exactly like you would for POST.
Explicitly set Content-Type — QUERY has no default assumption.
Build a small test collection:
javascript// pm.test examples for a QUERY request
Use Collection Runner (or Newman in CI) to fire the same QUERY N times in a loop and assert consistent responses — a fast, scriptable idempotency check.
If your Postman version won't let you type a custom verb in the dropdown, switch to raw request mode or override the method via a pre-request script.
3. Automation Testing
Most HTTP libraries don't have a .query() shortcut yet. Treat it as a custom verb with a body, same pattern you'd use for any non-standard method.
Java (REST-assured):
Python (requests):
JavaScript (fetch, Node 18+):
Scenarios worth automating and running in CI:
Idempotency regression — same QUERY 5x, assert byte-identical (or semantically identical) responses.
Cache key correctness — two near-identical bodies shouldn't collide in cache; two identical bodies should hit cache.
Contract tests — response schema stays stable regardless of query body shape (nested vs. flat filters).
Negative tests — oversized bodies, bad Accept-Query values, missing Content-Type.
Infra checks — confirm your WAF, API gateway, and load balancer actually pass QUERY through instead of blocking or silently rewriting it to POST.
4. Where AI Fits In
This is the part that saves the most time day-to-day:
Edge case generation: paste the RFC summary + your endpoint spec into an LLM and ask for edge cases you haven't thought of — malformed Accept-Query values, boundary body sizes, cache-key collision attempts.
Test script drafting: ask AI to draft Postman pm.test blocks or REST-assured/pytest scaffolding for idempotency and caching checks, then review and tighten them yourself.
Response diffing: have AI compare payloads across repeated QUERY calls and flag subtle non-idempotent behavior — a stray timestamp, reordered array, inconsistent pagination cursor.
Security review assist: since WAF/CSRF rules are often written before QUERY existed, AI can help draft candidate test payloads (oversized bodies, unusual Accept-Query values) for your authorized security testing — always within your org's scope and rules of engagement.
Doc gap-checking: feed your API docs to AI and ask it to flag places where Accept-Query support isn't documented or where QUERY behavior isn't clearly distinguished from GET/POST.
AI doesn't replace reading the spec — but it's genuinely good at generating breadth of coverage for a method this new, where nobody has a mature checklist yet.
Quick Reference
QUERY support is inconsistent across frameworks and infra right now — that's exactly the window where testing it thoroughly matters most, before assumptions get baked in.
*QUERY is still fresh and newborn *👶🏻 - expect inconsistent support across frameworks, proxies, and tools for a while. That's exactly why testing it thoroughly now, before it's baked into every stack, is worth the effort.
Have you run QUERY against your own stack yet? #testing #http #postman #automation #ai Curious what broke first — WAF, cache, or CORS. Drop it in the comments. Or reach me on email padmaraj (dot) nidagundi (at) gmail.com
Top comments (0)