Novo método HTTP - RFC 10008 · willybr

Depois de mais de uma década de discussão, o IETF publicou em junho de 2026 a RFC 10008, que padroniza o método HTTP QUERY. Se você já criou um endpoint POST /search na vida (e quem nunca?), este post é para você.

O problema que ele resolve

Todo mundo que constrói APIs REST já bateu nesse dilema:

GET é safe, idempotente e cacheável, mas os parâmetros vão na URL. Filtros complexos viram strings ilegíveis, URLs têm limite de tamanho que varia entre proxies, e URIs são logadas e salvas em bookmarks com muito mais frequência que corpos de requisição (péssimo para dados sensíveis).
POST aceita corpo, mas joga fora a garantia semântica. Nada no protocolo diz que aquele POST é uma leitura pura, então caches e intermediários assumem o pior.

O resultado prático: vemos muitas APIs com um POST /search que é semanticamente um GET disfarçado.

O QUERY fecha essa lacuna: corpo de requisição como o POST, semântica safe, idempotente e cacheável como o GET.

QUERY /users HTTP/1.1
Host: example.org
Content-Type: application/json

{
  "role": "admin",
  "sort": "name",
  "page": 1
}

Como o método está registrado no IANA como safe e idempotente, qualquer cliente, proxy ou cache genérico pode tratá-lo assim sem conhecer nada da sua API. A garantia sai da documentação e entra no protocolo.

Ficha técnica

Item	Detalhe
RFC	10008
Status	Proposed Standard (Standards Track, IETF)
Publicação	Junho de 2026
Autores	Julian Reschke (greenbytes), James M. Snell (Cloudflare), Mike Bishop (Akamai)
Working Group	HTTPBIS
Safe / Idempotente	Sim / Sim
Cacheável	Sim (com regras próprias)
CORS-safelisted	Não (exige preflight)

Curiosidade: a spec passou os primeiros anos se chamando SEARCH. A ideia nasceu em um draft individual de 2015, foi adotada pelo working group em março de 2021 e renomeada para QUERY em novembro de 2021, em parte para escapar da "bagagem" do WebDAV (que já tinha SEARCH, PROPFIND e REPORT, todos amarrados a formatos XML genéricos). Foram cerca de 11 anos do primeiro draft até o padrão.

Recursos interessantes da spec

Accept-Query: um header novo que permite ao servidor anunciar quais formatos de consulta aceita:

HTTP/1.1 200 OK
Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"

Equivalent resource: o servidor pode responder um QUERY com Content-Location (URI onde o resultado daquela consulta vive, útil para cache) e/ou Location (URI que permite repetir a mesma consulta via GET sem reenviar o corpo). Um 303 See Other pode redirecionar direto para o recurso equivalente.

Cache com corpo na chave: a chave de cache de uma resposta QUERY precisa incorporar o conteúdo completo do corpo, não só a URI. O cache pode normalizar diferenças insignificantes (formatação de JSON, encoding), mas essa normalização tem que bater com a interpretação do servidor, senão surgem cache hits falsos.

Estado do ecossistema (julho de 2026)

Aqui está a parte que interessa para quem quer usar em produção. Apesar da spec ter sido aprovada, provavelmente ainda teremos alguns anos até ser padrão e funcional nos principais frameworks e tools.

Node.js: faz parse do QUERY nativamente desde o início de 2024. Provavelmente o runtime mais adiantado.
OpenAPI 3.2: já documenta o método como cidadão de primeira classe.
ASP.NET 11: já reconhece o QUERY. Com OpenAPI 3.2 junto, a expectativa é que clientes gerados ofereçam o método antes da maioria dos servidores escritos à mão.
Spring: a issue original (#32975) ficou dois anos parada e foi superada pelo PR #34993, marcado como pronto para revisão na mesma semana da publicação da RFC. Mas até o início de julho de 2026, o enum RequestMethod ainda não tem QUERY, então não dá para rotear via @RequestMapping.
Rails: o Action Pack atualmente rejeita requisições QUERY antes mesmo de chegarem a um controller. Suporte precisa ser adicionado ao framework.
CDNs: Cloudflare e Akamai coescreveram a RFC, então a aposta é que suporte em nível de CDN chegue antes das integrações nos frameworks.

Pontos de atenção antes de adotar

CORS: QUERY não está na lista de métodos safelisted do fetch, então toda requisição cross-origin no browser dispara um preflight OPTIONS. Orçamente essa latência extra.
Segurança e infraestrutura: allowlists de métodos em WAFs, API gateways e middlewares de CSRF escritas antes de junho de 2026 provavelmente não mencionam QUERY. Alguns componentes vão rejeitar, outros podem rotear ou inspecionar diferente do POST. Vale revisar se suas regras tratam o método deliberadamente, e não por acidente.
Cache poisoning: caches que normalizam o corpo incorretamente podem retornar resposta cacheada para uma consulta que não corresponde. É uma classe de bug que cache baseado em GET não tem.
Nem tudo precisa de QUERY: a própria RFC avisa que, se a consulta é curta e simples, GET comum continua sendo a melhor opção.

Estratégia de migração sugerida

Para quem quer começar: exponha Accept-Query nos endpoints que suportam o método, mantenha a variante POST /search viva para clientes antigos e use OpenAPI 3.2 para documentar as duas. A tendência apontada pela comunidade (a thread no Hacker News sobre a RFC passou de 420 pontos) é que POST /search vire idioma legado nos próximos anos, do mesmo jeito que os headers X- viraram.

Fontes

E vocês, já têm algum POST /search esperando para virar QUERY?
Pretendem adotar assim que o framework de vocês suportar, ou vão esperar o ecossistema amadurecer?