DWEB 01.6 Métodos HTTP (GET, POST, PUT, PATCH, DELETE)

Toda requisição HTTP carrega, além da URL e dos cabeçalhos, uma intenção: o que o cliente quer fazer com aquele recurso? Ler? Criar? Modificar? Apagar? Essas intenções são expressas por meio dos chamados métodos HTTP (também chamados de verbos HTTP). Conhecer bem os métodos é o que diferencia um desenvolvedor que constrói aplicações coerentes de um que constrói aplicações que “funcionam de qualquer jeito”. Em uma API bem desenhada, ler o método de uma requisição já dá uma boa pista do que está acontecendo. Em uma API mal desenhada, o método pode estar lá, mas sem significar nada — e isso vira um problema cotidiano de quem mantém o sistema.

Por que existem métodos diferentes?

Pense em qualquer pasta de documentos no seu computador. Há, basicamente, quatro coisas que você pode fazer com um documento: ler, criar, atualizar e apagar. Esse conjunto de operações é tão fundamental que, na área de tecnologia, recebeu até um nome: CRUD (Create, Read, Update, Delete — Criar, Ler, Atualizar, Apagar). Quase todo sistema com algum tipo de dado, em algum lugar do seu interior, faz essas quatro coisas.

O HTTP foi projetado, desde a sua origem, para dar suporte a esse modelo. Em vez de criar uma URL diferente para cada operação (/criar-produto, /ler-produto, /atualizar-produto, /apagar-produto), a proposta foi mais elegante: usar a mesma URL e variar o método conforme a intenção. Veja a tabela:

Operação CRUD Método HTTP Exemplo conceitual
Ler GET “Me dê o produto 123”
Criar POST “Crie um novo produto com esses dados”
Atualizar (total) PUT “Substitua o produto 123 por estes dados”
Atualizar (parcial) PATCH “Mude apenas o preço do produto 123”
Apagar DELETE “Apague o produto 123”

Essa é a base do estilo de arquitetura conhecido como REST, que domina o desenvolvimento de APIs web. Você não precisa, neste curso, dominar REST como teoria — vamos voltar a esse assunto na Aula 13. Por enquanto, basta entender que cada método tem um significado padronizado e que respeitar esse significado é uma decisão importante de quem desenvolve.

Os cinco métodos que você verá todos os dias

Vamos olhar, um por um, os cinco métodos que aparecem em quase toda aplicação web.

GET — para ler

O método GET é o mais usado da web. Toda vez que você abre uma página, o navegador faz, internamente, um GET para o endereço dela. Quando você clica em um link, é um GET. Quando uma imagem carrega na página, é um GET para a URL dessa imagem. O GET é o método da leitura.

Características importantes do GET:

  • Não tem corpo de requisição. Os dados que ele envia, se houver, vão na query string (estudada no Tópico 1.5).
  • É idempotente: fazer o mesmo GET dez vezes seguidas deve produzir o mesmo resultado, sem efeitos colaterais. Ler um recurso não pode mudá-lo.
  • Pode ser cacheado pelo navegador e por servidores intermediários, exatamente porque é só leitura.

Exemplo conceitual:

GET /produtos/123 HTTP/1.1
Host: loja-exemplo.com.br

Em termos de resultado, isso pede “os dados do produto 123” ao servidor.

POST — para criar (ou enviar dados)

O método POST é usado, classicamente, para criar um novo recurso no servidor. É o método natural para envios de formulários (criar um cadastro, fazer um pedido, postar um comentário) e para uploads.

Diferenças importantes em relação ao GET:

  • Tem corpo de requisição: os dados vão no corpo, não na URL.
  • Não é idempotente: fazer o mesmo POST duas vezes pode criar dois registros diferentes. Por isso, ao enviar um formulário, navegadores costumam pedir confirmação quando o usuário tenta atualizar a página depois.
  • Normalmente não é cacheado.

Exemplo conceitual:

POST /produtos HTTP/1.1
Host: loja-exemplo.com.br
Content-Type: application/json

{
  "nome": "Caneca artesanal",
  "preco": 49.90,
  "estoque": 30
}

Isso diz ao servidor: “crie um produto com esses dados”. O servidor, em resposta bem-sucedida, costuma retornar o novo produto recém-criado, já com seu identificador (ID).

PUT — para substituir

O método PUT é usado para substituir um recurso existente, por inteiro, por novos dados. Ele requer que o cliente envie todos os campos do recurso, não apenas os que mudaram.

Características:

  • Tem corpo, como o POST.
  • É idempotente: enviar o mesmo PUT várias vezes deve produzir o mesmo estado final no servidor.
  • Aponta sempre para um recurso específico (geralmente identificado por um ID no path).

Exemplo conceitual:

PUT /produtos/123 HTTP/1.1
Host: loja-exemplo.com.br
Content-Type: application/json

{
  "nome": "Caneca artesanal personalizada",
  "preco": 59.90,
  "estoque": 25
}

Isso diz ao servidor: “substitua o produto 123 por estes dados”. Se algum campo não for enviado, dependendo da implementação, ele pode ficar em branco ou ser interpretado como “não mudou” — e essa ambiguidade é exatamente uma das razões pelas quais o PATCH foi criado.

PATCH — para atualizar parcialmente

O método PATCH é mais novo e foi pensado para modificar apenas parte de um recurso. Em vez de enviar todos os campos como no PUT, você envia só o que vai mudar.

Características:

  • Tem corpo.
  • A idempotência depende de como o PATCH é interpretado pelo servidor. Em boas implementações, ele é idempotente; em outras, não.
  • É mais econômico em rede e mais elegante quando o recurso tem muitos campos.

Exemplo conceitual:

PATCH /produtos/123 HTTP/1.1
Host: loja-exemplo.com.br
Content-Type: application/json

{
  "preco": 54.90
}

Isso diz ao servidor: “mude apenas o preço do produto 123, deixe o resto como está”. Bem mais sucinto que o PUT equivalente.

DELETE — para apagar

O método DELETE faz o que o nome diz: pede ao servidor para apagar um recurso.

Características:

  • Em geral, não tem corpo (mas o protocolo permite que tenha, dependendo do servidor).
  • É idempotente: apagar duas vezes o mesmo recurso produz o mesmo estado final (recurso ausente). A segunda chamada, geralmente, retorna um status indicando que o recurso já não existe.

Exemplo conceitual:

DELETE /produtos/123 HTTP/1.1
Host: loja-exemplo.com.br

Isso diz: “apague o produto 123”. Em resposta bem-sucedida, o servidor costuma retornar um status 204 No Content (que estudaremos no próximo tópico) — sem corpo.

A questão da idempotência

A palavra idempotente pode parecer técnica, mas é um conceito intuitivo. Uma operação é idempotente quando executá-la várias vezes produz o mesmo resultado final que executá-la uma vez.

  • Apertar o botão do elevador uma vez ou apertar dez vezes: o elevador continua vindo só uma vez. Idempotente.
  • Discar um número de telefone uma vez ou cinco: cinco ligações distintas. Não idempotente.

Em HTTP:

  • GET é idempotente — só lê.
  • PUT é idempotente — substitui pelo mesmo conteúdo.
  • DELETE é idempotente — depois da primeira chamada, o recurso já não existe.
  • POST não é idempotente — cada chamada pode criar um novo registro.
  • PATCH depende da implementação.

Por que isso importa? Porque, em sistemas reais, requisições falham, conexões caem, usuários clicam duas vezes. Saber se é seguro repetir uma operação determina o que a aplicação deve fazer nessas situações — e como o usuário será informado.

Outros métodos que existem (mas você verá menos)

Além dos cinco principais, há outros métodos no padrão HTTP que aparecem com menos frequência no dia a dia do front-end, mas que vale conhecer:

  • HEAD — igual ao GET, mas pede apenas os cabeçalhos da resposta, sem o corpo. Útil para verificar se um recurso existe ou para inspecionar metadados sem baixar o conteúdo todo.
  • OPTIONS — usado para perguntar ao servidor quais métodos e cabeçalhos são permitidos. Aparece com frequência no contexto de CORS (Cross-Origin Resource Sharing), uma política de segurança que controla quem pode chamar uma API a partir de outra origem. Voltaremos a esse tema na Aula 13.

Caso ilustrativo: a vida de um produto em uma loja online

Imagine que você é o desenvolvedor front-end de uma loja online de pequenos artigos. A jornada de um único produto, do ponto de vista das requisições HTTP, é mais ou menos esta:

  1. O dono da loja entra no painel administrativo e cria um novo produto. O front-end envia: POST /produtos com os dados do produto.
  2. O servidor responde com o produto criado, incluindo seu novo ID, digamos, 123.
  3. Um visitante acessa a loja e clica no produto. O navegador faz: GET /produtos/123.
  4. O dono percebe que escreveu o preço errado. Ele edita o campo no painel. O front-end envia: PATCH /produtos/123 com { "preco": 39.90 }.
  5. Tempos depois, o produto sai de linha. O dono pede para removê-lo. O front-end envia: DELETE /produtos/123.

Note que a URL /produtos/123 é a mesma em vários pontos da jornada. O que muda é o método, e é esse método que define a intenção. Essa elegância é exatamente o que torna APIs REST agradáveis de usar e fáceis de documentar.

Caso ilustrativo, criado para fins didáticos.

Momento de aplicação prática

Reflita sobre uma aplicação web que você usa com frequência (rede social, e-mail, sistema de mensagens). Para cada uma das ações a seguir, qual método HTTP você imagina que esteja sendo usado por baixo dos panos?

  1. Carregar a tela inicial.
  2. Postar uma nova mensagem.
  3. Marcar uma mensagem como lida.
  4. Excluir uma conversa antiga.
  5. Editar seu nome de exibição no perfil.
  6. Pesquisar por uma palavra-chave.

Respostas comentadas:

  1. GET — leitura da tela.
  2. POST — criação de uma nova mensagem.
  3. PATCH (ou às vezes PUT) — alteração parcial de um campo.
  4. DELETE — remoção.
  5. PATCH (ou às vezes PUT) — alteração de um campo do perfil.
  6. GET (com query string, do tipo ?q=palavra-chave) — leitura filtrada.

Se você acertou a maioria, está navegando bem. Se errou alguma, releia a definição correspondente; o entendimento intuitivo dos métodos é importante porque, na hora de programar, ele vai guiar suas decisões.

Armadilha comum

Um erro frequente em projetos mal feitos é usar GET para ações que modificam dados. Isso pode parecer prático, mas é uma péssima ideia. Mecanismos de busca, navegadores e ferramentas intermediárias acreditam que GET é seguro, e podem repeti-lo automaticamente — o que, em um endpoint que apaga ou modifica algo, vira um desastre. Existe um caso clássico, comentado em literatura de boas práticas web: páginas administrativas com links do tipo <a href="/deletar?id=42">Deletar</a>. Em algum momento, alguma ferramenta passou por essas páginas, seguiu os links automaticamente — e apagou tudo. A lição é: use o método correto, sempre. Operações que modificam dados pedem POST, PUT, PATCH ou DELETE. Nunca GET.

O que vem a seguir

Já sabemos pedir as coisas. Mas como saber se o pedido deu certo? E quando dá errado, como saber por que deu errado? A resposta a essas duas perguntas mora em duas peças complementares: os códigos de status (que o servidor devolve com cada resposta) e os cabeçalhos (que carregam metadados sobre o pedido e sobre a resposta). É o tema do próximo tópico — e é o que vai começar a transformar você em alguém capaz de diagnosticar problemas de aplicações web, e não apenas usá-las.

Tópico anterior
Back to Aula
Próximo Tópico