RFC 10008: O novo método HTTP QUERY

Propósito e Semântica de QUERY

• Introduz QUERY como “GET com corpo”: somente leitura, seguro e idempotente.
• O objetivo principal é suportar consultas complexas/grandes (por exemplo, GraphQL, filtros ricos, imagens) sem limites de tamanho de URL.
• Destinado apenas à recuperação de dados; a semântica é semelhante à de GET, mas os parâmetros da requisição ficam no corpo.

Cache, Idempotência e Segurança

• Como QUERY é seguro e idempotente, intermediários e clientes podem armazená-lo em cache e tentar novamente automaticamente, ao contrário de POST.
• Debate sobre chaves de cache:
  • Preocupação: usar o corpo inteiro como chave de cache cria chaves ilimitadas, controladas pelo usuário, e complexidade (ordenação, normalização, hashing).
  • Contra-argumentos: isso é opcional; caches podem fazer hash do corpo, ou, melhor, servidores podem responder com uma URL curta Location que então pode ser armazenada em cache via GET.
• Efeitos colaterais como logging e quotas são tratados como “ignorados” no nível da semântica HTTP, da mesma forma que em GET.

GET-com-corpo vs Novo Método

• Alguns argumentam que a especificação deveria apenas padronizar um corpo em GET.
• Outros observam que muitos proxies/servidores ignoram, descartam ou rejeitam corpos em GET, e isso já é desencorajado há muito tempo, então adaptar semântica é inseguro.
• O novo método evita alteração silenciosa: QUERY não suportado tende a falhar claramente (por exemplo, 405) em vez de descartar dados.

Intermediários e Compatibilidade

• Preocupação: muitas caixas intermediárias historicamente lidam mal com métodos desconhecidos ou com qualquer método-com-corpo que não entendam.
• Sem suporte amplo de gateways/CDNs, POST com cabeçalhos personalizados continua sendo a escolha pragmática para alguns.
• QUERY também precisa lidar com CORS: atualmente não está na safelist, então os navegadores fazem preflight, mesmo sendo seguro.

Casos de Uso e Reações de Desenvolvedores

• Usos sugeridos: consultas grandes de GraphQL, filtros de busca complexos, padrões dry-run vs commit (QUERY depois POST), consultas semelhantes às de banco de dados, consultas de IA em streaming com event streams.
• Alguns veem isso como uma correção semântica limpa para gambiarras de “POST /search” e um melhor alinhamento com o modelo de métodos do HTTP.
• Céticos veem como excesso: mais complexidade, novo plumbing e mais uma nuance que desenvolvedores precisam aprender, para um problema já “bom o suficiente” com GET/POST.

Formulários HTML, Favoritos e UX

• Há interesse em method="query" em formulários HTML para evitar avisos de “reenviar dados de POST” e mapear melhor operações seguras.
• Desejo mais amplo de permitir que formulários usem mais verbos HTTP (PUT/DELETE/etc.) para alinhar interações humanas com a semântica REST.
• Preocupação com a possibilidade de salvar nos favoritos se os parâmetros de consulta ficarem no corpo; discutem-se mitigações via URLs GET geradas pelo servidor.

Debates de Nome e Conceito

• Alguns acham “QUERY” confuso, dada a terminologia existente de “query string”.
• Alguns argumentam que verbos HTTP não deveriam codificar semântica de negócio, vendo isso como sobreprojeto impulsionado por REST; outros respondem que o HTTP sempre associou semântica aos métodos.