Métodos HTTP - GET VS POST

O HTTP (Hypertext Transfer Protocol) foi criado para fornecer comunicação entre clientes e um servidor. Ele opera em um modelo de requisição-resposta: o cliente envia uma requisição que especifica um método HTTP (também chamado de verbo HTTP), e o método informa ao servidor que tipo de ação realizar no recurso alvo.

Um <form> HTML nativamente suporta apenas dois desses métodos — GET e POST — por meio do atributo method. Por isso, esses dois são os que a maioria dos desenvolvedores HTML encontram primeiro. Mas o HTTP em si define vários outros métodos (PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT), que você acessa por meio de JavaScript (fetch) ou do seu backend ao construir REST APIs.

Duas Propriedades Fundamentais: Safe e Idempotent

Antes de analisar os métodos individualmente, dois termos descrevem como cada um se comporta. Eles são usados ao longo desta página e nas especificações HTTP.

Safe — o método é somente leitura. Ele não deve alterar o estado do servidor. Buscar uma página nunca deve criar, atualizar ou excluir nada. GET, HEAD e OPTIONS são safe.
Idempotent — fazer a mesma requisição uma ou várias vezes tem o mesmo efeito no servidor. Enviar um DELETE para um recurso uma vez, ou enviá-lo cinco vezes, deixa o recurso excluído de qualquer forma. Métodos safe são sempre idempotent, mas um método pode ser idempotent sem ser safe (por exemplo, PUT e DELETE).

Veja como os métodos comuns se comparam:

Método	Safe	Idempotent	Possui corpo na requisição	Uso típico
GET	Sim	Sim	Não	Recuperar um recurso
HEAD	Sim	Sim	Não	Recuperar apenas os cabeçalhos
OPTIONS	Sim	Sim	Não	Descobrir métodos permitidos / preflight CORS
POST	Não	Não	Sim	Criar um recurso ou enviar dados
PUT	Não	Sim	Sim	Substituir / atualizar um recurso em uma URL conhecida
PATCH	Não	Não garantido	Sim	Aplicar uma modificação parcial
DELETE	Não	Sim	Geralmente não	Remover um recurso

Informação

PATCH não é garantido como idempotent. Dependendo de como o patch é escrito, pode ser idempotent (por exemplo, "definir status como active") ou pode não ser (por exemplo, "incrementar o contador em 1"). A especificação HTTP deixa isso a cargo da implementação.

Método GET

O método GET solicita dados de uma fonte especificada. Ele é safe e idempotent: apenas lê dados e nunca altera nada no servidor. Requisições GET podem ser armazenadas em cache e permanecem no histórico do navegador. Também podem ser adicionadas aos favoritos.

Ele nunca deve ser usado para dados sensíveis, pois a string de consulta faz parte da URL (que é registrada em log, armazenada em cache e adicionada aos favoritos). Requisições GET têm restrições práticas de comprimento e devem ser usadas apenas para recuperar dados.

Perigo

As strings de consulta (pares nome/valor) são enviadas na URL da requisição GET.

Exemplo de um input type text com o método get

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="get">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br />
      <br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Experimente Você Mesmo »

Método POST

O método POST envia dados para processamento a uma fonte especificada. Ele não é safe nem idempotent: pode alterar o estado do servidor, e enviar o mesmo formulário duas vezes geralmente cria dois registros — é por isso que os navegadores alertam antes de reenviar dados POST. Ao contrário do método GET, requisições POST nunca são armazenadas em cache, não permanecem no histórico do navegador e não podem ser adicionadas aos favoritos. Além disso, requisições POST não estão sujeitas a restrições de comprimento de URL, embora os servidores geralmente imponham seus próprios limites de tamanho de corpo.

Perigo

As strings de consulta (pares nome/valor) são enviadas no corpo da mensagem HTTP da requisição POST.

Exemplo de um formulário com o método "post"

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="post">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br /><br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Experimente Você Mesmo »

Comparação dos Métodos GET e POST

Recurso	GET	POST
Botão Voltar/Recarregar	Inofensivo	Recarregar a página vai reenviar os dados do formulário. O navegador deve alertar que os dados serão reenviados nesse caso.
Pode ser adicionado aos favoritos	Sim	Não
Pode ser armazenado em cache	Sim	Não
Tipo de codificação	application/x-www-form-urlencoded	application/x-www-form-urlencoded ou multipart/form-data
Histórico	Permanece no histórico do navegador.	Não permanece no histórico do navegador.
Restrições de comprimento de dados	Ao enviar dados, o método GET adiciona os dados à URL. O comprimento da URL é limitado (comprimento máximo de URL é 2048 caracteres).	Não possui restrições de comprimento de URL, embora os servidores geralmente imponham limites de tamanho de corpo.
Restrição de tipo de dados	Principalmente caracteres ASCII, embora UTF-8 seja suportado via codificação percentual.	Não possui restrições. Dados binários também são permitidos.
Segurança	Menos seguro que POST, pois os dados enviados fazem parte da URL.	POST é mais seguro que GET, pois os dados não ficam visíveis na URL ou no histórico do navegador. No entanto, ambos transmitem dados em texto simples via HTTP e requerem HTTPS para segurança real.
Visibilidade	Os dados ficam visíveis para todos na URL.	Não exibe os dados na URL.

Nota O elemento <form> HTML suporta nativamente apenas GET e POST por meio do seu atributo method. Para usar PUT, PATCH ou DELETE, você normalmente envia a requisição com JavaScript (fetch) ou deixa seu framework backend substituir o método.

HEAD, OPTIONS e CONNECT

Além de GET e POST, o HTTP define vários outros métodos. Três deles são descritos aqui; os métodos orientados a recursos PUT, PATCH e DELETE são abordados em suas próprias seções.

Método	Safe	Idempotent	Descrição
HEAD	Sim	Sim	Idêntico ao GET, mas o servidor retorna apenas os cabeçalhos HTTP, não o corpo da resposta.
OPTIONS	Sim	Sim	Pergunta ao servidor quais métodos e opções estão disponíveis para um recurso.
CONNECT	Não	Não	Estabelece um túnel para o servidor, usado por proxies para HTTPS.

HEAD

HEAD funciona exatamente como GET, mas o servidor omite o corpo e retorna apenas os cabeçalhos. Por ser safe e idempotent, é ideal quando você precisa de metadados sem baixar o recurso completo — por exemplo, verificar o Content-Length de um arquivo grande antes de baixar, ou testar se uma URL ainda está acessível (seu código de status) sem transferir seu conteúdo.

OPTIONS

OPTIONS pergunta ao servidor o que ele permite para um recurso. A resposta geralmente inclui um cabeçalho Allow listando os métodos suportados (por exemplo, Allow: GET, POST, OPTIONS). Seu uso mais importante no mundo real é a requisição de preflight CORS: antes que um navegador envie um PUT, DELETE de origem cruzada, ou uma requisição com cabeçalhos personalizados, ele automaticamente dispara uma requisição OPTIONS para confirmar que o servidor permite a chamada real. Raramente você escreve requisições OPTIONS manualmente — o navegador faz isso por você.

CONNECT

CONNECT instrui um servidor proxy a estabelecer um túnel TCP/IP transparente para o destino, mais comumente para que o tráfego HTTPS criptografado possa passar pelo proxy sem ser lido. Ele é usado pela infraestrutura em vez de código de aplicação, portanto você quase nunca o chamará diretamente.

Método PUT

O método PUT é usado principalmente para substituir ou atualizar um recurso. O cliente envia a URL do recurso alvo junto com um corpo de requisição que contém a representação completa e atualizada desse recurso. PUT também pode criar um recurso quando o cliente (não o servidor) decide a URL do recurso.

PUT não é safe, porque altera o estado no servidor, mas é idempotent: se você enviar a mesma requisição PUT duas vezes, o recurso termina exatamente no mesmo estado que estaria após uma única requisição — o corpo substitui completamente o que havia antes.

O exemplo abaixo pede ao servidor para armazenar o corpo JSON fornecido como o recurso em /users/42:

Métodos HTTP - Exemplo de requisição PUT

PUT /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive
Content-Type: application/json
Content-Length: 54

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Após armazenar o corpo, o servidor pode responder assim:

Métodos HTTP - Exemplo de resposta PUT

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Content-Length: 54
Connection: keep-alive

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Método PATCH

O método PATCH é usado para modificação parcial de um recurso. Ao contrário do PUT, não precisa do recurso completo — o corpo contém apenas as alterações a serem aplicadas.

PATCH não é safe, e não é garantido como idempotent: dependendo do formato do patch, pode ou não produzir o mesmo resultado quando repetido. Um patch como "definir status como active" é idempotent, mas um patch como "adicionar 1 a views" não é. Colisões entre duas requisições PATCH também podem ser perigosas, porque alguns formatos de patch esperam aplicar alterações a partir de um estado base compartilhado; caso contrário, o recurso pode ser corrompido.

O exemplo abaixo altera apenas o campo email do usuário, deixando todos os outros campos intactos:

Métodos HTTP - Exemplo de requisição PATCH

PATCH /users/42 HTTP/1.1
Host: www.w3docs.com
Content-Type: application/json
Content-Length: 31

{ "email": "[email protected]" }

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Connection: keep-alive

Método DELETE

Como o nome sugere, este método remove o recurso identificado por uma URL. DELETE não é safe, mas é idempotent: uma vez que um recurso é excluído, chamar DELETE novamente o deixa excluído — o estado final é o mesmo. (Chamadas repetidas podem retornar um código de status diferente, como 404 Not Found na segunda tentativa, mas o estado do servidor não muda mais.)

O exemplo abaixo pede ao servidor para excluir o usuário em /users/42:

Exemplo de requisição DELETE

DELETE /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive

Após excluir o recurso, o servidor geralmente responde com 204 No Content — um status de sucesso que não carrega corpo de resposta:

Exemplo de resposta DELETE

HTTP/1.1 204 No Content
Date: Mon, 15 Jun 2026 14:53:57 GMT
Connection: keep-alive

Um 200 OK (opcionalmente com um corpo descrevendo o recurso excluído) também é uma resposta DELETE válida. Consulte mensagens de status HTTP para a lista completa de códigos de status.