Também disponível em: English · Español · Français · العربية
Métodos HTTP: seguros, idempotentes e cacheáveis
Todos os métodos que a IANA registrou, e o que cada um significa para um rastreador, um proxy e um cache.
O que é um método HTTP?
Um método HTTP — o verbo no início de um pedido, GET ou POST ou DELETE — diz o que o cliente quer fazer com o recurso que nomeia. Existem muito mais do que se costuma encontrar: o registro da IANA guarda 41 nomes, e só nove vêm da especificação central do HTTP. O resto chega do WebDAV, das extensões de versionamento, do CalDAV, do HTTP/2 e de três especificações avulsas.
A RFC 9110 dá três propriedades a cada método. Ele é seguro se sua semântica é essencialmente de leitura, de modo que um rastreador pode enviá-lo sem receio. É idempotente se enviar o mesmo pedido duas vezes tem o efeito de enviá-lo uma, de modo que um proxy pode repeti-lo depois de uma conexão caída. E é cacheável se um cache pode guardar a resposta e reutilizá-la mais tarde.
Essas três respostas são o que uma página sobre métodos HTTP deveria dar, e elas não moram todas no mesmo lugar — que é a razão de esta página existir em vez de uma cópia do registro.
Como usar
- Digite o nome de um método. Maiúsculas não importam. Você recebe as três propriedades, o que cada uma significa na prática para um cliente e para um cache, e um link para a seção da RFC que diz isso.
- Ou busque no registro inteiro. A tabela abaixo tem os 41 nomes. Buscar um número de RFC — 9110, 4918 — traz de volta tudo o que aquele documento define.
- Reduza aos que você vai encontrar de fato. Uma caixa de seleção deixa a tabela com os nove nomes que a própria RFC 9110 registra, que são todos os métodos que a maioria das APIs chega a enviar.
A propriedade que o registro não anota
A seção 16.1.1 da RFC 9110 lista os campos que o registro de um método deve carregar: o nome, se é seguro, se é idempotente e um ponteiro para a especificação. Quatro campos, e a cacheabilidade não está entre eles. Só que a seção 16.1.2 do mesmo documento diz que a definição de um método novo precisa indicar se ele é seguro, idempotente e cacheável. Três propriedades citadas a uma seção de distância, duas delas anotadas.
Então a terceira tem de ser lida nos documentos que definem cada método, e são treze deles. Fazer isso dá uma resposta limpa para quase todas as linhas e uma resposta incômoda para o resto: 3 métodos são cacheáveis sem ressalva, outros 3 apenas sob condições declaradas, 26 explicitamente não são, e 9 especificações nunca mencionam cache.
Esse silêncio não é uma incógnita, e esta é a frase que torna a tabela completa em vez de parcial. Seção 9.2.3: para que um cache guarde e use uma resposta, o método precisa permitir o cache explicitamente e detalhar sob quais condições, e um método cuja definição não faz isso não pode ser cacheado. O silêncio é uma recusa por padrão, escrita no próprio padrão. A tabela ainda mostra essas nove linhas como «não diz» e não como «não», porque o que uma especificação recusa e o que ela nunca considerou são fatos diferentes, e só um deles pode ser citado numa revisão de código.
As fórmulas também diferem, e vale ver quais. Oito métodos dizem que as respostas NÃO DEVEM ser cacheadas, o que obriga o cache. Dez — a família de versionamento, mais MKCALENDAR — exigem em vez disso que o servidor envie Cache-Control: no-cache, o que obriga o servidor. SEARCH diz apenas NÃO DEVERIAM. PROPFIND diz que os resultados podem ser cacheados, com cuidado. A tabela registra qual fórmula produziu cada resposta.
As linhas que quase todo mundo erra
PATCH não é idempotente. Ele aparece ao lado de PUT em todo tutorial de REST e se comporta de outro jeito: aplicar o mesmo patch duas vezes pode não equivaler a aplicá-lo uma vez, então o registro o anota como nem seguro nem idempotente, e a RFC 9110 diz que um proxy não deve repetir automaticamente um pedido desses. DELETE, por outro lado, é idempotente apesar de soar como o verbo mais destrutivo da lista — apagar algo duas vezes o deixa apagado.
Seguro não quer dizer cacheável. Nove métodos são seguros e só três — GET, HEAD e QUERY — são cacheáveis sem ressalva. OPTIONS e TRACE são de leitura e suas respostas nunca são cacheáveis, dito explicitamente. REPORT é seguro, idempotente, e sua especificação não diz nada sobre cache.
O contrário também falha: POST e PATCH não são seguros nem idempotentes, e ambos são cacheáveis sob condições. Uma resposta a POST pode ser guardada quando carrega informação explícita de frescor e um Content-Location igual ao alvo do pedido — e aí só pode ser usada para responder a um GET ou HEAD posterior, nunca a outro POST. A RFC 9110 observa de passagem que, de todo modo, a esmagadora maioria dos caches implementa apenas GET e HEAD, o que é uma especificação admitindo que a realidade seguiu outro caminho.
Mais duas curiosidades. QUERY virou método de via padrão em junho de 2026: seguro, idempotente, cacheável e com corpo no pedido — exatamente o que as pessoas quiseram toda vez que tentaram enfiar uma busca longa num GET. Sua chave de cache precisa incorporar o corpo, que é precisamente por que demorou tanto. E o registro contém uma entrada chamada simplesmente asterisco, que não é um método: está reservada para que ninguém jamais registre um, porque esse nome colidiria com o curinga de cabeçalhos como Access-Control-Request-Method.
O que esta página não consegue dizer
Estas são propriedades do método, não promessas sobre um servidor. Um servidor pode implementar GET de modo que apague algo; a especificação é clara que isso torna o servidor errado, não o GET inseguro. O que as propriedades compram é o direito de supor: um rastreador pré-carregando métodos seguros, um proxy repetindo os idempotentes, um cache guardando os cacheáveis, sem pedir licença a ninguém.
A tabela é também o retrato de um registro que cresce. QUERY foi acrescentado em 2026 e nada aqui prevê o que virá depois. Onde uma linha diz que uma especificação se cala, isso descreve o documento como ele está, não uma previsão de que continuará calado.
E um método estar registrado não diz nada sobre haver algo que o suporte. A maioria destes 41 nomes pertence ao WebDAV e suas extensões, e um servidor web comum responde a eles com 405.
Por que é grátis?
O registro inteiro são alguns kilobytes que viajam com a página e são consultados no seu navegador. Nada do que você digita é enviado, nada é registrado e não há conta a criar.
Sem cadastro, sem limites e sem marca d'água em nada que você copiar.