O protocolo HTTP ganhou um novo método: query

Em junho de 2026, o IETF publicou a RFC 10008, oficializando o método QUERY. É o primeiro método novo do HTTP desde 2010, quando o método PATCH foi padronizado.

O problema que ele resolve

Toda as vezes em que é necessário fazer uma busca complexa, com filtros aninhados, múltiplos campos, ordenação e paginação, o desenvolvedor backend esbarra no mesmo dilema: usar GET ou POST?

• GET: os parâmetros vão na URL, que tem limite de tamanho (proxies e servidores normalmente cortam a requisição em poucos KB). Assim, filtros complexos viram strings ilegíveis e ainda podem vazar dados sensíveis em logs.
• POST: funciona bem para enviar corpos grandes e estruturados, mas não é seguro (safe), nem idempotente por definição. Isso quebra cache, dificulta o retry automático em timeout e faz o servidor recalcular tudo a cada chamada, mesmo sendo só uma leitura.

De fato, faltava um método que unisse o corpo estruturado do POST com as características de idempotência e segurança do GET.

Note que “seguro” (safe) é um termo técnico do HTTP que não tem nada a ver com segurança/criptografia. Ele vem direto da RFC 9110 (a especificação atual de semântica HTTP). Método seguro é um método que não causa efeitos colaterais no servidor. Na prática, isso significa que a requisição é só de leitura, ou seja, ela não cria, altera nem apaga nada. O servidor pode receber a mesma chamada mil vezes que o estado dos dados continua exatamente igual.

O que isso significa na prática?

Vamos imaginar uma busca de produtos com filtros de categoria, faixa de preço e ordenação. Com GET, a URL ficaria assim:

/produtos?categoria=eletronicos&preco_min=100&preco_max=500&ordenar=preco_asc&tags[]=promocao&tags[]=frete-gratis

Por sua vez, com o método QUERY, a mesma busca fica assim:

QUERY /produtos HTTP/1.1
Host: minhaloja.com
Content-Type: application/json
Accept-Query: application/json
 
{
  "categoria": "eletronicos",
  "preco": { "min": 100, "max": 500 },
  "ordenar": "preco_asc",
  "tags": ["promocao", "frete-gratis"]
}

Veja que temos o mesmo corpo estruturado que mandaríamos uma requisção POST, só que agora, o servidor e toda a infraestrutura no meio do caminho, sabem que essa chamada é segura, idempotente e pode ser cacheada.

Vantagens

• Cache funcional para requisições com corpo: algo que proxies, CDNs e browsers nunca conseguiram fazer direito com POST.
• Retry seguro: como é idempotente, uma requisição que deu timeout pode ser reenviada sem medo de efeitos colaterais, respeitando a restrição stateless das aplicações REST.
• Filtros complexos sem gambiarra de URL: chega de serializar objetos aninhados em query strings.
• Semântica clara para toda a infraestrutura: WAFs, API gateways e ferramentas de observabilidade passam a “entender” que aquela chamada é só leitura, mesmo tendo corpo.

O problema sempre existiu, e era mitigado com muita criatividade e hard code do desenvolvedor. Agora temos um jeito padronizado no nível do protocolo para resolvê-lo de uma vez por todas.

Comparando os três métodos

Conclusão

Frente ao exposto, acredito que o método GET deverá ser usado em consultas simples, aquelas que usam poucos ou nenhum parâmetro. Para consultas complexas, vamos de método QUERY!

A decisão do que fazer em sistemas que já estão em produção deve passar por uma análise crítica: vale a pena refatorar o código?

De qualquer forma, fique ligado, pois o suporte já está chegando em servidores e frameworks (Tomcat 12, Jetty, .NET 10, entre outros), então vale ficar de olho: o método QUERY deve se tornar padrão em APIs de busca nos próximos anos.