explainx / blog
RFC 10008 (June 2026) adds HTTP QUERY — safe, idempotent, cacheable reads with a request body. First new HTTP method since PATCH (2010). vs GET, POST, when to use it, Accept-Query, CORS, and adoption reality.
Jun 27, 2026
The restaurant analogy, HTTP methods, status codes, JSON, API keys, rate limiting — everything a beginner needs to understand and call APIs, with real working examples in curl, Python, and JavaScript.
Jun 27, 2026
Webhooks are APIs in reverse — the other service calls you when something happens. This guide covers building a webhook endpoint, verifying signatures, testing with ngrok, and handling retries safely.
Jul 3, 2026
Not a curriculum — a sequence. What a child is ready for at 5, at 8, at 11, and at 14, which milestones actually matter, and the one thing to keep constant the whole way: the kid commands, the machine serves.
Does HTTP finally have GET with a body? Almost — RFC 10008 (The HTTP QUERY Method, published June 15, 2026) standardizes QUERY: the first new HTTP method in 16 years since PATCH (RFC 5789, 2010).
X/Grok trending framed it simply: no more stuffing complex search filters into 800-character URLs; no more POST for read-only search. The RFC authors — Julian Reschke, James Snell (Cloudflare), Mike Bishop (Akamai) — spent a decade in the HTTPBIS working group getting there.
| Question | Answer |
|---|---|
| What is QUERY? | Safe + idempotent + cacheable request with a body describing the query |
| GET vs QUERY? | GET = params in URL; QUERY = params in body (no URL length pain) |
| POST vs QUERY? | POST = may mutate state; QUERY = read-only semantics for the target resource |
| First since when? | PATCH (2010) — QUERY registered June 2026 |
| Header to discover? | Accept-Query lists supported query media types |
| Browser catch? | CORS preflight required — QUERY is not safelisted |
| Zero writes? | HTTP-safe ≠ DB-read-only — logging and temp URLs still happen |
Classic list/search pattern today:
GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.org
Works until it does not:
| GET pain | Why it hurts |
|---|---|
| URL size | RFC 9110 recommends supporting ~8000 octets — unknown limits through proxies |
| Encoding overhead | Nested JSON filters in query strings are ugly and lossy |
| Logging & bookmarks | URIs show up in logs, analytics, browser history |
| Resource explosion | Every filter combo becomes a distinct cache key / "resource" |
Teams then abuse POST for reads:
POST /feed HTTP/1.1
Host: example.org
Content-Type: application/json
{"q":"foo","filters":{"tags":["ai","api"]},"limit":10}
POST works mechanically — but retries are scary, caches ignore it for reads, and intermediaries cannot tell this is a safe search without out-of-band docs.
QUERY spans the gap:
QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/json
Accept: application/json
{"q":"foo","filters":{"tags":["ai","api"]},"limit":10}
Same body affordance as POST; safe and idempotent semantics as GET.
| GET | QUERY | POST | |
|---|---|---|---|
| Safe | yes | yes | potentially no |
| Idempotent | yes | yes | potentially no |
| Request body | no defined semantics | expected | expected |
| Cacheable | yes | yes | only for future GET/HEAD in some cases |
| URI for query itself | yes (by definition) | optional (Location) | no |
| URI for result | optional | optional (Content-Location) | optional |
Source: RFC 10008 Section 1, Table 1.
The body + Content-Type define the query. RFC examples include:
application/x-www-form-urlencodedapplication/sqlapplication/jsonpath (RFC 9535)application/xslt+xmlServers MUST reject missing or inconsistent Content-Type (400, 415, 422 as appropriate).
Accept-QueryHEAD /contacts HTTP/1.1
Host: example.org
HTTP/1.1 200 OK
Accept-Query: application/x-www-form-urlencoded, application/sql
Or check OPTIONS → Allow: GET, QUERY, HEAD.
Successful QUERY responses may include:
Content-Location — GET this URI for these resultsLocation — GET this URI to re-run the same query laterThat lets clients move from QUERY → GET for polling and conditional requests (If-None-Match, If-Modified-Since).
Caches may store QUERY responses, but the cache key must include the request body and metadata. Mis-normalization = false cache hits. Mitigation: Location URIs clients can GET instead.
Per Fetch spec, QUERY is not CORS-safelisted — browsers will preflight cross-origin QUERY. Plan for OPTIONS handling in public APIs.
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json
select=surname,givenname,email&limit=10&match=%22email=*@example.*%22
HTTP/1.1 200 OK
Content-Type: application/json
[
{"surname":"Smith","givenname":"John","email":"[email protected]"},
{"surname":"Jones","givenname":"Sally","email":"[email protected]"}
]
For short queries, RFC itself says: if it's this small, use GET.
RFC defines safe as: no change to the target resource's state. Servers may still:
@yacineMTB on X (replying to adoption threads): "Queries, unfortunately, are not 0 writes for the vast majority of cases." Correct at the infrastructure layer.
QUERY standardizes HTTP semantics for search-shaped REST endpoints. It does not replace:
It does give OpenAPI designers a first-class verb for POST /search anti-patterns.
| Today | Tomorrow |
|---|---|
POST /api/users/search | QUERY /api/users |
GET /api/logs?filter=... (10KB URL) | QUERY /api/logs + JSON body |
POST /reports/run (read-only) | QUERY /reports |
| GraphQL POST (unchanged) | Still GraphQL |
Checklist before shipping QUERY:
Accept-Query on resources that support multiple query formatsQUERY method; verify cache key includes bodyAccess-Control-Allow-Methods: QUERY| Layer | June 2026 status |
|---|---|
| IETF / IANA | ✅ RFC 10008 Proposed Standard |
| curl / HTTP clients | Manual --request QUERY possible where supported |
| Frameworks (Express, FastAPI, etc.) | Patch incoming; route registration varies |
| API gateways (Cloudflare, Akamai) | Authors' employers — watch vendor blogs |
Browsers fetch() | No default yet; preflight either way |
| OpenAPI 3.x | Community extensions / 3.1 query verb discussions |
Vincent Eliezer's X quip — "Even internet protocols are shipping faster than GTA 6" — is fair. Standards ship ≠ your stack supports it tomorrow.
Why not SEARCH? Early drafts used SEARCH (WebDAV heritage). RFC appendix explains QUERY won — clearer relation to URI query components, less WebDAV baggage, explicit media-type semantics.
Can I use QUERY from Claude Code / agents? Yes once your HTTP client allows custom methods — same as any REST surface agents call via MCP or tools. Document idempotency so agents can retry safely.
Does QUERY help AI search APIs? Indirectly — fat retrieval filters (RAG metadata, JSONPath over corpora) fit QUERY's body model better than GET. Pair with GEO content strategy on the data you expose, not the HTTP verb alone.
RFC 10008 published June 15, 2026. HTTP client and framework support evolves — verify your stack before production QUERY endpoints.