Durante dezesseis anos, desenvolvedores que precisavam fazer perguntas complexas a um servidor ficaram presos a uma solução de contorno. Quando um payload de busca ficava grande demais para uma URL, ou quando filtros aninhados e parâmetros sensíveis se recusavam a caber dentro de uma query string, a única opção prática era o POST. Ele carregava os bytes, mas mentia sobre a intenção. O POST sinaliza uma mudança de estado. Usá-lo para uma operação de apenas leitura forçava todo o caminho de rede — caches, proxies e navegadores — a tratar uma consulta inocente como se ela pudesse alterar um banco de dados.

Esse compromisso finalmente chegou ao fim. Em junho de 2026, o IETF publicou a RFC 10008, padronizando formalmente o método QUERY. É o primeiro novo método HTTP desde que o PATCH foi introduzido em 2010. O QUERY existe especificamente para requisições seguras e idempotentes que, por acaso, precisam de um corpo. Ele não altera o estado do servidor. Repetir a mesma requisição produz o mesmo resultado. Ele é cacheável, o que significa que intermediários podem armazenar e reutilizar a resposta. E, ao contrário do GET, ele permite um payload de dados assim como o POST.

Consultas GraphQL e endpoints de busca REST complexos são os maiores vencedores. Você não precisa mais espremer sessenta parâmetros de consulta em uma URL ou esconder um documento de filtro JSON dentro de um corpo de POST que os intermediários se recusarão a colocar em cache. A semântica agora é honesta.

Mas uma RFC é apenas tinta no papel. Entre sua aplicação e seus usuários existe uma espessa camada de infraestrutura, e a maior parte dela nunca ouviu falar de QUERY.

O problema de cache ainda não foi resolvido

Com uma requisição GET, o cache é direto. A chave de cache é a URI. Dois usuários acessando a mesma URL recebem a mesma resposta armazenada, assumindo que os cabeçalhos permitam.

O QUERY quebra esse modelo porque os parâmetros da requisição residem no corpo. Para que um cache reconheça que duas requisições são idênticas, a chave de cache deve incorporar tanto a URI quanto o conteúdo do corpo. Esse requisito introduz um real atrito operacional.

Primeiro, servidores de borda e CDNs devem fazer o buffer de todo o corpo da requisição antes de poderem computar um hash. Isso consome memória e tempo no nó de borda. Segundo, duas consultas logicamente idênticas podem não produzir os mesmos bytes. Um cliente pode enviar {"status":"active"} enquanto outro envia {"status": "active"} com espaços em branco ou ordem de chaves diferentes. A menos que a camada de cache analise, normalize e canonicize o corpo — ordenando as chaves JSON, removendo formatações insignificantes e lidando com diferenças de codificação — a mesma pergunta falhará no cache todas as vezes.

Mais criticamente, as principais CDNs ainda não particionam o cache por corpo de requisição para o QUERY. A Cloudflare, por exemplo, não trata o corpo como parte da chave de cache para este método em sua forma atual. Se você implementar o QUERY assumindo que "cacheável" significa "em cache", poderá ver erros de colisão, falhas de cache universais ou respostas que vazam entre requisições não relacionadas. Até que seu provedor publique suporte explícito, assuma que o QUERY não é significativamente cacheável em produção.

Suas ferramentas provavelmente serão as primeiras a bloqueá-lo

Cada requisição HTTP atravessa uma pilha de middleboxes, e a maioria delas impõe regras rígidas sobre quais métodos são permitidos.

Web Application Firewalls e API gateways geralmente dependem de listas de permissão (allowlists) explícitas. Um conjunto de regras típico permite GET, POST, PUT, DELETE e PATCH. Qualquer outra coisa é descartada ou respondida com um 405 Method Not Allowed. O QUERY atingirá essas barreiras antes mesmo de chegar ao código da sua aplicação.

Motores de regras de segurança adicionam outro obstáculo. Alguns sistemas de detecção de intrusão assumem que uma requisição que carrega um corpo