A nova método HTTP QUERY explicada

Artigo original ↗ Discussão no Hacker News ↗

O que o QUERY pretende resolver

  • Visto como uma formalização de “GET com corpo”: seguro, idempotente, cacheável, mas podendo transportar um corpo de requisição.
  • Destinado a substituir gambiarras como GET-com-corpo ou POST-para-consultas (por exemplo, busca, consultas GraphQL).
  • Defensores dizem que ele esclarece a semântica para intermediários: “isto pode ser cacheado, é somente leitura e tem um corpo.”

Por que não simplesmente corrigir o GET?

  • Um grupo: simplesmente padronizar GET-com-corpo; QUERY é redundante, “inchaço” de padrões estilo XKCD.
  • Contraponto: muitos proxies, WAFs, CDNs e frameworks existentes removem ou rejeitam corpos em GET ou os tratam como sem sentido.
  • Mudar a semântica do GET criaria comportamento indefinido em sistemas legados; um novo método pode falhar de forma limpa com 405 e permitir fallback para POST.
  • Alguns argumentam que ambos os caminhos exigem atualizar a infraestrutura de qualquer forma; veem QUERY como marketing, não como necessidade técnica.

Compatibilidade, middleboxes e navegadores

  • Há preocupações de que middlewares “caixa-preta” mal mantidos possam lidar mal com novos verbos ou travar.
  • Outros dizem que os padrões precisam evoluir apesar do hardware e software legados; infraestrutura quebrada deve ser corrigida.
  • Vários observam que é improvável que navegadores implementem QUERY tão cedo (ou ao menos não há garantia disso); isso limita a adoção voltada à web.
  • O cabeçalho Accept-Query e OPTIONS/405 são citados como mecanismos para negociar suporte.

Casos de uso propostos

  • APIs de busca como Elastic/OpenSearch atualmente abusando de GET-com-corpo ou POST; QUERY seria um encaixe natural.
  • GraphQL: usar QUERY para consultas somente leitura, POST para mutações.
  • Filtragem/busca complexa em aplicativos web: corpos JSON em vez de strings de consulta longas.
  • Busca reversa por imagem e outras consultas baseadas em arquivo ou binário.

Cache, semântica e REST

  • QUERY é definido como cacheável e idempotente; isso abre cache em CDN/proxy, ao contrário do POST.
  • Céticos observam chaves de cache práticas: corpos não têm uma forma canônica padrão (ordenação de JSON, espaços em branco), complicando caches compartilhados.
  • Alguns argumentam que QUERY melhora a clareza de REST/CRUD ao separar o GET simples por URL de consultas mais complexas; outros dizem que é possível modelar consultas como recursos (POST para criar, depois GET).

Segurança, WAFs e pontos de dor práticos

  • Muitos citam sistemas do mundo real que rejeitam ou removem corpos em GET (WAFs, CloudFront, gateways de API restritivos).
  • QUERY é visto como uma forma de evitar esses comportamentos indefinidos e regras de segurança que tratam GET-com-corpo como suspeito.
  • Outros alertam que o próprio QUERY não será suportado por esses sistemas inicialmente, então a migração continua não trivial.