# Comparação de métodos HTTP > Informe de um a quatro métodos HTTP (experimente "get vs query") para ver os fatos de registro de cada um: seguro, idempotente, cacheável, semântica do corpo da requisição, presença na safelist do CORS, suporte em formulários HTML e a RFC que o define - além de exatamente quais propriedades diferem. Inclui o QUERY, o método da RFC 10008 registrado em junho de 2026. - Tool: https://ronutz.com/pt-BR/tools/http-methods-comparison - Family: Redes --- ## O que ela faz Informe de um a quatro nomes de métodos HTTP (Hypertext Transfer Protocol, protocolo de transferência de hipertexto) e a ferramenta retorna os fatos de protocolo de cada um: se é seguro, idempotente e cacheável, qual a semântica do corpo da requisição, se o CORS (Cross-Origin Resource Sharing, compartilhamento de recursos entre origens) permite que navegadores o enviem sem preflight (a requisição OPTIONS de pedido de permissão que o navegador dispara antes de qualquer requisição entre origens que não seja simples), se formulários HTML conseguem produzi-lo declarativamente e qual RFC o define. Peça dois ou mais ("get vs query") e ela também nomeia exatamente as propriedades em que diferem. A tabela cobre os nove métodos centrais da RFC 9110, o PATCH (RFC 5789), o trio WebDAV PROPFIND, REPORT e SEARCH, e a linha manchete: o QUERY, registrado pela RFC 10008 em junho de 2026 - o primeiro método HTTP novo desde o PATCH, em 2010. ## O vocabulário, com precisão Seguro significa que o cliente não pede mudança de estado; idempotente significa que repetir a requisição idêntica deixa o servidor no mesmo estado - o que torna repetições automáticas legais. Ambos são promessas registradas na IANA sobre intenção: um cache, proxy ou camada de retry genérica pode agir sobre elas sem saber nada da sua API. Nenhum dos dois diz nada sobre o payload: um corpo de QUERY carrega a mesma tentativa de injeção que um corpo de POST, e é por isso que a nota final da ferramenta insiste em inspeção de nível POST para o QUERY. A cacheabilidade tem três valores honestos na tabela: GET e HEAD são o par cacheável; respostas de POST e PATCH só são cacheáveis com informação explícita de frescor (na prática, quase nunca); o QUERY é cacheável por projeto, com a exigência da RFC 10008 de que a chave de cache incorpore o conteúdo da requisição - o mecanismo que torna cacheável uma requisição com corpo, e o ponto exato onde uma implementação de cache desleixada vira envenenamento de cache. A semântica do corpo separa quatro casos que o ecossistema vive confundindo: corpos que são o ponto (POST, PUT, PATCH, QUERY, o trio WebDAV), corpos sem semântica definida que servidores podem rejeitar de cara (GET, HEAD, DELETE - a RFC 9110 diz isso explicitamente), corpos permitidos porém sem significado (OPTIONS) e corpos proibidos (CONNECT, TRACE). ## Por que o QUERY é a linha interessante O QUERY é o meio que faltava, e a tabela o torna visível: seguro + idempotente + cacheável como GET, corpo como POST. Ele existe porque o GET força a consulta para dentro da URL (limites de tamanho, dor de codificação, vazamento em logs e no Referer), enquanto o POST /search mente para a infraestrutura - nada no protocolo o marca como somente leitura, então nada no meio do caminho consegue cachear ou repetir. A comparação "post vs query" mostra cinco propriedades virando de uma vez; "get vs query" mostra as três que importam para a adoção: o corpo, o preflight do CORS (o QUERY não está na safelist) e os formulários HTML (um form com method="query" hoje recua para GET e descarta o corpo). ## Exemplos resolvidos `query` sozinho dá a linha completa da RFC 10008. `get vs query` responde à pergunta canônica com três diferenças. `post,query` mostra a história da migração: cinco viradas. `put delete` mostra o par que é idempotente sem ser seguro. `trace` e `connect` mostram os dois métodos proibidos de ter corpo. `search` conta a história do nome: os primeiros rascunhos do QUERY se chamavam SEARCH, até a renomeação de 2021. ## Procedência Cada valor de seguro/idempotente é a própria coluna do Registro de Métodos HTTP da IANA, cruzada com a RFC 9110 §9.3, a RFC 10008, a RFC 5789 e as especificações WebDAV (RFC 4918, 3253, 5323); a safelist do CORS segue a especificação Fetch do WHATWG, e o status dos formulários, a discussão aberta no HTML do WHATWG. Todas as fontes foram buscadas em 20/07/2026. A ferramenta traz 19 vetores dourados fixando cada linha, então qualquer deriva na tabela quebra o build. ## Standards and references - [RFC 9110 (HTTP Semantics) §9 - method definitions, safe/idempotent/cacheable properties, body-semantics warnings for GET/HEAD/DELETE, content prohibitions for CONNECT/TRACE](https://www.rfc-editor.org/rfc/rfc9110.html) - the nine core-method rows: safety, idempotency, cacheability (GET/HEAD; POST with explicit freshness), and request-body semantics - [RFC 10008 (The HTTP QUERY Method, June 2026) - QUERY registered safe + idempotent; cacheable with the cache key incorporating the request content (§2.7); Accept-Query field; CORS preflight required; Content-Type enforced, sniffing forbidden](https://www.rfc-editor.org/rfc/rfc10008.html) - the QUERY row and its notes: the first new HTTP method registration since PATCH (2010) - [IANA Hypertext Transfer Protocol (HTTP) Method Registry - the authoritative safe/idempotent columns per registered method, including QUERY (added by RFC 10008) and the WebDAV trio PROPFIND/REPORT/SEARCH](https://www.iana.org/assignments/http-methods/http-methods.xhtml) - cross-check of every safe/idempotent value in the table - [RFC 5789 (PATCH Method for HTTP, 2010) - neither safe nor idempotent; responses cacheable only with explicit freshness information](https://www.rfc-editor.org/rfc/rfc5789.html) - the PATCH row - [RFC 4918 (PROPFIND), RFC 3253 (REPORT), RFC 5323 (SEARCH) - the WebDAV-lineage safe, idempotent, body-carrying methods that preceded QUERY; RFC 10008 Appendix B explains why QUERY got a clean start instead](https://www.rfc-editor.org/rfc/rfc4918.html) - the PROPFIND/REPORT/SEARCH rows and the naming-history note ## Related reading - [HTTP QUERY: a leitura que finalmente carrega um corpo](https://ronutz.com/pt-BR/learn/http-query-method.md): A RFC 10008 (junho de 2026) deu ao HTTP seu primeiro método novo desde 2010: o QUERY é seguro, idempotente e cacheável como o GET, mas carrega um corpo de requisição como o POST. O que ele corrige, como funcionam seu cache e sua descoberta, por que 'seguro' não é 'inofensivo' e o que cada camada da infraestrutura precisa conferir antes de o tráfego QUERY chegar. - [Métodos HTTP: Os Verbos da Web](https://ronutz.com/pt-BR/learn/http-methods-the-verbs.md): GET, HEAD, POST, PUT, DELETE, PATCH, OPTIONS, TRACE, CONNECT - e agora QUERY. O que cada método promete, por que 'safe' e 'idempotente' são as duas propriedades que de fato importam (para caches, retentativas, proxies e crawlers), por que formulários HTML só aprenderam dois verbos, e como ler a alma de uma API pelos métodos que ela aceita. - [QUERY Encontra o BIG-IP: LTM, iRules e o Veredito do Advanced WAF](https://ronutz.com/pt-BR/learn/bigip-http-query-method.md): Como o BIG-IP lida com o novo método HTTP QUERY (RFC 10008): o perfil HTTP do LTM deixa métodos desconhecidos passarem por padrão, o Advanced WAF bloqueia o QUERY como Illegal method até você permiti-lo, e vinte anos de ambiguidade nas iRules entre HTTP::method e HTTP::query de repente importam. O que auditar, onde clicar e por que o corpo continua recebendo inspeção completa.