Resumo

  • QUERY leva a expressão no conteúdo da requisição e está registrada como segura e idempotente. A classificação obriga a implementação; não certifica automaticamente que um handler esteja livre de efeitos de negócio.
  • Conteúdo e metadados entram na chave de cache. Redirecionamento, validação, Accept-Query e URI equivalente distribuem decisões entre cliente, cache e origem, sem tornar o corpo secreto.

Pense em uma busca com filtros aninhados e projeções extensas. GET preserva a linguagem de uma leitura, mas o RFC 9110 não define semântica geral para conteúdo recebido em GET. POST aceita um corpo, porém uma falha de conexão deixa o cliente sem a presunção de que repetir a chamada seja seguro.

Publicado em junho de 2026 como Proposed Standard, o RFC 10008 cria QUERY para esse intervalo. O corpo é obrigatório; o media type informa o formato; conteúdo e metadados relevantes definem a consulta ao recurso-alvo. A IANA registra QUERY como segura e idempotente e Accept-Query como campo permanente.

QUERY não é GET com corpo nem POST rebatizado. Segurança significa que o efeito solicitado é leitura. Idempotência significa que várias requisições idênticas têm o mesmo efeito pretendido de uma só, não que a resposta seja sempre igual. Cobrar, reservar, aprovar ou consumir um direito continua sendo mutação, mesmo se o código impedir duplicatas.

A propriedade do método cria confiança operacional

Clientes automatizam métodos seguros. Bibliotecas podem repetir métodos idempotentes após uma interrupção de execução incerta. Caches aplicam regras somente aos métodos que entendem. Ao expor QUERY, a origem autoriza esses atores a confiar nas propriedades registradas.

Uma anotação de rota não prova o comportamento. A evidência precisa juntar método, fingerprint do conteúdo, media type, identidade, execução, efeitos e representação entregue. Em um retry, deve mostrar se a primeira tentativa chegou à aplicação e se a segunda gerou qualquer efeito vedado.

Telemetria incidental pode acompanhar uma leitura. Mas avanço de fila, débito de cota, consumo de token ou emissão de ordem são consequências solicitadas. O teste acompanha a realidade do usuário e de terceiros, não a aparência da função interna.

O corpo integra a identidade do cache

O RFC 10008 exige que a chave de uma resposta QUERY inclua o conteúdo e seus metadados relevantes. Mesma URI com filtros diferentes significa perguntas diferentes. Um cache que usa apenas método e URI pode entregar a resposta de um cliente a outro.

Para derivar a chave, o intermediário pode precisar ler o corpo inteiro. Limite, memória, latência e backpressure tornam-se decisões de produção. A expressão saiu da URI, mas passou a ser material de identidade retido em outra camada.

Normalização pode aproximar grafias semanticamente iguais quando o cache entende o formato. Também pode fundir consultas distintas. Ignorar whitespace definido como irrelevante é diferente de ordenar uma lista posicional. no-transform orienta intermediários, porém não comprova que nenhum componente canonizou o material da chave.

Os testes devem explorar duas direções: múltiplas codificações do mesmo significado e significados diferentes com aparência similar. Unicode, números, campos repetidos, defaults, compressão, assinaturas e partição de autorização precisam permanecer visíveis. Na dúvida, preservar a diferença custa hits; inventar igualdade pode devolver dados errados.

Dar nome ao resultado muda sua vida útil

O recurso equivalente deriva do alvo, do conteúdo QUERY e dos metadados. A origem pode atribuir uma URI para recuperação posterior via GET. Uma expressão efêmera passa a ter um nome copiável e armazenável.

Location e Content-Location não são sinônimos. Em resposta QUERY bem-sucedida, Location pode indicar um recurso equivalente ou de consulta acessível por GET. Content-Location liga a representação retornada a uma URI segundo a semântica HTTP. Reduzir ambos a “URL canônica” apaga a declaração feita pela origem.

O nome também pode vazar a consulta. Incluir filtro confidencial ou conta na URI devolve o dado a históricos, logs e referências. Um identificador opaco diminui a exposição, mas exige política de expiração, revogação e acesso. A URI pode sobreviver à autorização usada para criá-la.

O RFC 3986 fornece sintaxe, não decide sigilo ou duração. A origem que nomeia controla uma superfície durável e responde por ela.

Redirecionar é decidir o destino do método

QUERY é preservada em 301, 302, 307 e 308; as exceções históricas do POST não valem. O 303 manda fazer GET. Assim, alguns status retransmitem conteúdo e outro aponta para um recurso.

Um gateway que transforme QUERY em GET pode perder o corpo ou colocá-lo na URI. Se a transformar em POST, remove a propriedade usada no retry. Cada status, mudança de origem e regra de credenciais merece teste próprio.

Na QUERY condicional, o validador se refere à representação que um GET do recurso equivalente selecionaria. Negociação e autorização continuam valendo. O hash da expressão não substitui o identificador da representação.

Accept-Query é evidência fresca e limitada

Accept-Query anuncia media types com uma List do RFC 9651. O valor se aplica ao mesmo path, desconsiderando o query component; entre observações, usa-se a mais recente ainda fresca.

Isso não garante que toda expressão seja válida nem que todos os nós concordem. É preciso registrar resposta de origem, frescor, path e versão de implantação.

No navegador existe outra fronteira. QUERY não está entre os métodos CORS simples do Fetch Standard; uso cross-origin exige preflight. Suporte na aplicação falha se gateway, WAF ou configuração CORS bloquear o verbo.

Fora da URI não é fora da custódia

QUERY pode evitar que filtros apareçam em links e logs de URI. O conteúdo ainda passa por cliente, ferramentas do navegador, terminação TLS, gateways, cache, tracing e origem. Pode ser copiado, amostrado e retransmitido. Um redirect o envia de novo; uma URI equivalente pode torná-lo público.

A distinção de Lu Heng entre domínio formal e realidade prática dos dados mostra o problema: a origem define a semântica, mas vários operadores têm custódia concreta.

Seu modelo de especificação mínima e decisão localizada mantém o protocolo enxuto. A camada comum define método, cache, redirect e anúncio. A origem escolhe linguagens e nomes; o cliente decide emitir e repetir; o cache só reutiliza se preservar identidade.

A primazia do código em execução define a prova: o RFC documenta a promessa; traces demonstram segurança, idempotência, chave completa e nome não revelador.