Métodos de requisição HTTP

Consulte qualquer método de requisição HTTP registrado: o que ele faz, qual especificação o define e se é seguro e idempotente. A tabela cobre os nove métodos principais e as extensões WebDAV, DeltaV e CalDAV.

Funciona localmente no seu navegador

Ver categoria: Referências e consultas (21)

Os métodos de requisição HTTP indicam o que uma requisição deve fazer. Nove métodos principais vêm do próprio HTTP — GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE e PATCH —; os demais são extensões registradas para WebDAV, versionamento e calendários, além de dois métodos removidos nas revisões posteriores do HTTP. A tabela lista todos os métodos do registro de métodos HTTP da IANA, com a especificação que os define e se são seguros e idempotentes.

Método	Definido em	Seguro / idempotente	Finalidade
Métodos principais
GET	RFC 9110 §9.3.1	sim / sim	Obtém uma representação do recurso de destino.
HEAD	RFC 9110 §9.3.2	sim / sim	Obtém apenas os cabeçalhos da resposta, sem o corpo.
POST	RFC 9110 §9.3.3	não / não	Envia dados ao recurso de destino para processamento; muitas vezes cria um recurso ou inicia uma ação.
PUT	RFC 9110 §9.3.4	não / sim	Cria o recurso de destino ou o substitui pelo conteúdo da requisição.
DELETE	RFC 9110 §9.3.5	não / sim	Remove o recurso de destino.
CONNECT	RFC 9110 §9.3.6	não / não	Abre um túnel para a autoridade de destino, normalmente por meio de um proxy.
OPTIONS	RFC 9110 §9.3.7	sim / sim	Pergunta quais métodos e opções o recurso de destino aceita.
TRACE	RFC 9110 §9.3.8	sim / sim	Pede ao servidor que devolva a requisição recebida para diagnóstico.
PATCH	RFC 5789 §2	não / não	Aplica ao recurso de destino as mudanças descritas no conteúdo da requisição.
Extensões WebDAV
PROPFIND	RFC 4918 §9.1	sim / sim	Lê as propriedades de um recurso; o cabeçalho Depth escolhe a profundidade da árvore.
PROPPATCH	RFC 4918 §9.2	não / sim	Define ou remove várias propriedades de um recurso em uma única requisição.
MKCOL	RFC 4918 §9.3	não / sim	Cria uma coleção, o recurso do WebDAV parecido com uma pasta.
COPY	RFC 4918 §9.8	não / sim	Copia um recurso para o URI indicado no cabeçalho Destination.
MOVE	RFC 4918 §9.9	não / sim	Move um recurso para o URI indicado no cabeçalho Destination.
LOCK	RFC 4918 §9.10	não / não	Bloqueia um recurso para escrita e devolve um token de bloqueio.
UNLOCK	RFC 4918 §9.11	não / sim	Libera um bloqueio com o token do cabeçalho Lock-Token.
ACL	RFC 3744 §8.1	não / sim	Lê ou altera a lista de controle de acesso de um recurso.
SEARCH	RFC 5323 §2	sim / sim	Executa uma consulta DASL em uma coleção e devolve os recursos encontrados.
MKCALENDAR	RFC 4791 §5.3.1	não / sim	Cria uma coleção de calendário com suas propriedades.
BIND	RFC 5842 §4	não / sim	Adiciona um recurso existente a uma coleção como nova vinculação.
UNBIND	RFC 5842 §5	não / sim	Remove uma vinculação de uma coleção.
REBIND	RFC 5842 §6	não / sim	Move uma vinculação de uma coleção para outra.
ORDERPATCH	RFC 3648 §7	não / sim	Muda a posição dos membros de uma coleção ordenada.
MKREDIRECTREF	RFC 4437 §6	não / sim	Cria um recurso de referência de redirecionamento que aponta para outro URI.
UPDATEREDIRECTREF	RFC 4437 §7	não / sim	Altera o URI de destino de um recurso de referência de redirecionamento.
Extensões de versionamento (DeltaV)
VERSION-CONTROL	RFC 3253 §3.5	não / sim	Coloca um recurso sob controle de versão.
REPORT	RFC 3253 §3.6	sim / sim	Pede um relatório de versão, de propriedades ou DAV sobre um recurso.
CHECKOUT	RFC 3253 §8.8	não / sim	Torna um recurso versionado gravável ou cria um recurso de trabalho.
CHECKIN	RFC 3253 §9.4	não / sim	Salva as mudanças como uma nova versão e devolve o recurso para somente leitura.
UNCHECKOUT	RFC 3253 §4.5	não / sim	Cancela o checkout e descarta as mudanças não confirmadas.
MKWORKSPACE	RFC 3253 §6.3	não / sim	Cria um workspace para trabalho versionado.
UPDATE	RFC 3253 §7.1	não / sim	Aplica as mudanças de uma versão a outro recurso.
LABEL	RFC 3253 §8.2	não / sim	Adiciona ou remove um rótulo nas versões.
MERGE	RFC 3253 §11.2	não / sim	Mescla as diferenças entre dois históricos de versão.
BASELINE-CONTROL	RFC 3253 §12.6	não / sim	Transforma uma coleção em uma coleção controlada por linhas de base.
MKACTIVITY	RFC 3253 §13.5	não / sim	Cria uma atividade que agrupa mudanças de vários recursos.
Outros métodos registrados
QUERY	RFC 10008 §2	sim / sim	Envia uma consulta segura e idempotente com os parâmetros no conteúdo.
PRI	RFC 9113 §3.4	sim / sim	Enviado apenas no preâmbulo de conexão HTTP/2, antes de qualquer quadro.
Removidos do HTTP
LINK	RFC 2068 §19.6.1.2	não / sim	Definido na RFC 2068 para criar ligações entre recursos; as revisões posteriores do HTTP o removeram.
UNLINK	RFC 2068 §19.6.1.3	não / sim	Definido na RFC 2068 para remover ligações entre recursos; as revisões posteriores do HTTP o removeram.

Como ler esta referência de métodos

Esta página reúne todos os métodos do registro de métodos HTTP da IANA, mantido pela IETF. Cada linha traz o nome do método, a especificação que o define, se ele é seguro e idempotente e uma linha sobre o que faz.

As linhas vêm com a página: nada é gerado em tempo de execução, não é preciso digitar nada e nenhuma requisição é enviada enquanto você lê. O campo de busca apenas filtra a tabela no seu navegador.

Filtre a tabela digitando parte do nome de um método, um número de RFC ou uma palavra da descrição; o contador mostra quantas entradas continuam visíveis.

Leia a coluna Definido em para chegar à especificação. O sinal de seção indica o trecho que define o método, por exemplo RFC 9110 §9.3.1 para GET.

Confira Seguro / idempotente antes de repetir uma requisição: um método seguro é definido como somente leitura, e um método idempotente pode ser reenviado com o mesmo efeito.

Use Copiar linha quando precisar da linha inteira, ou selecione uma célula. A tabela é uma referência: nada é convertido, guardado ou enviado.

O que significam as colunas e o registro

Seguro e idempotente

Um método é seguro quando a especificação o define como somente leitura: GET, HEAD, OPTIONS, TRACE, PROPFIND, REPORT, SEARCH, QUERY e PRI são marcados como seguros no registro. Seguro descreve a intenção, não os efeitos que o servidor decidir acrescentar: uma requisição GET ainda pode ser registrada, contada ou cobrada.

Um método é idempotente quando repetir a mesma requisição tem o mesmo efeito de enviá-la uma vez. PUT, DELETE e quase todos os métodos WebDAV e DeltaV são idempotentes; POST, PATCH, CONNECT e LOCK não são, então um cliente ou proxy não deve repeti-los automaticamente após um timeout.

O registro é a fonte

A IANA atualiza o registro quando novos métodos são publicados, e esta tabela o acompanha: o nome, as marcas de seguro e idempotente e a primeira especificação da lista. Quando o registro traz outras especificações — MKCOL é ampliado pela RFC 5689, PROPFIND e REPORT pela RFC 8144 — mostramos a RFC que define o método.

Existem métodos fora do registro. O UPnP SSDP envia M-SEARCH por UDP, a RFC 2774 define métodos de extensão com prefixo M-, como M-GET, e muitas APIs inventam os próprios verbos; um servidor que não reconhece o método responde 405 Method Not Allowed e um proxy pode recusá-lo de imediato.

Métodos removidos e específicos de protocolo

LINK e UNLINK vêm da RFC 2068, a primeira especificação do HTTP/1.1, e foram removidos depois: o registro ainda os lista com a referência do rascunho, mas nenhuma especificação atual do HTTP os usa.

PRI é enviado uma vez por conexão, no preâmbulo do HTTP/2, antes de qualquer quadro; o registro também lista a forma de asterisco, usada como OPTIONS * para falar com o servidor inteiro em vez de um recurso. É fácil confundir os dois ao ler um log de requisições.