13 Padrões de Requisição HTTP que Todo Dev Deve Conhecer

Introdução

Cada requisição HTTP carrega um método que diz ao servidor qual ação executar. Conhecer esses padrões é o primeiro passo para projetar APIs que fazem sentido, e evitar aquela confusão entre POST e PUT que todo dev já enfrentou. Abaixo, os 13 métodos que você precisa ter no radar, do mais comum ao mais específico.

1. GET

O GET solicita a representação de um recurso. É o método mais usado na web: toda vez que você abre uma página ou consome uma API pública, está fazendo um GET. Por definição, GET não deve alterar estado no servidor, é seguro e idempotente. Se sua requisição GET está criando registros no banco, algo está errado.

2. POST

POST envia dados para criar um novo recurso. Diferente do GET, ele não é idempotente: enviar o mesmo POST duas vezes pode gerar dois recursos distintos. É o método padrão para formulários web e criação de entidades em APIs REST. Um exemplo: cadastrar um novo usuário sempre usa POST.

3. PUT

PUT substitui completamente um recurso existente pelo que foi enviado no corpo da requisição. Se o recurso não existe, alguns servidores criam um novo. PUT é idempotente, chamá-lo duas vezes com os mesmos dados produz o mesmo estado final. Use PUT quando quiser sobrescrever um recurso inteiro, como atualizar o perfil completo de um cliente.

4. PATCH

PATCH aplica modificações parciais em um recurso. Enquanto PUT substitui o objeto todo, PATCH altera apenas os campos enviados. Não é necessariamente idempotente: duas chamadas PATCH consecutivas podem ter efeitos diferentes se dependerem do estado atual. Prefira PATCH para atualizações incrementais, como alterar apenas o e-mail de um usuário.

5. DELETE

DELETE remove um recurso específico. É idempotente: após a primeira chamada bem-sucedida, chamadas subsequentes retornam 404 (não encontrado) ou 204 (sem conteúdo), mas o estado final é o mesmo, recurso inexistente. Use DELETE com cuidado em operações críticas, sempre validando permissões antes.

6. HEAD

HEAD é idêntico ao GET, mas o servidor retorna apenas os cabeçalhos da resposta, sem o corpo. Útil para verificar metadados (tamanho do arquivo, última modificação, tipo de conteúdo) sem baixar o recurso inteiro. Economiza banda em verificações de cache e validação de links.

7. OPTIONS

OPTIONS descreve os métodos HTTP suportados por um recurso. O servidor responde com o cabeçalho Allow listando os métodos permitidos (ex.: Allow: GET, POST, DELETE). Essencial para APIs REST que expõem capacidades dinâmicas e para o mecanismo de CORS em requisições cross-origin.

8. TRACE

TRACE ecoa a requisição recebida pelo servidor, permitindo ao cliente ver o que chegou após proxies e gateways. É usado para diagnóstico de rede e depuração de intermediários. Por questões de segurança, muitos servidores desabilitam TRACE para evitar ataques de Cross-Site Tracing.

9. CONNECT

CONNECT estabelece um túnel para o servidor de destino, geralmente usado para comunicação HTTPS através de proxies. O cliente pede ao proxy para criar uma conexão TCP direta com o host alvo. É o método que permite navegar em sites seguros através de proxies corporativos.

10. GET condicional

Não é um método separado, mas uma variação do GET usando cabeçalhos como If-Modified-Since ou If-None-Match. O servidor retorna 304 (Not Modified) se o recurso não mudou, evitando transferência desnecessária de dados. Reduz latência e consumo de banda em aplicações que consultam recursos com frequência.

11. Requisição com cache (Cache-Control)

A combinação de métodos com cabeçalhos de cache define como intermediários armazenam respostas. Por exemplo, GET com Cache-Control: max-age=3600 permite cache por uma hora. POST, PUT e DELETE geralmente invalidam caches existentes. Entender essa interação é crucial para performance em larga escala.

12. Métodos seguros vs. idempotentes

Seguro (GET, HEAD, OPTIONS, TRACE) significa que a requisição não altera estado no servidor. Idempotente (GET, PUT, DELETE, HEAD, OPTIONS, TRACE) significa que múltiplas requisições idênticas produzem o mesmo resultado que uma única. POST e PATCH não são idempotentes por padrão. Essa distinção guia decisões de design e tolerância a falhas.

13. Boas práticas de seleção

Ao projetar uma API, escolha o método pela semântica, não pela conveniência: use GET para leitura, POST para criação, PUT para substituição total, PATCH para atualização parcial, DELETE para remoção. Evite usar POST para tudo, isso quebra a previsibilidade que torna APIs REST fáceis de consumir. Documente os métodos esperados para cada endpoint.

Fechamento: como escolher o método certo

Não existe método universal. Para APIs públicas, priorize GET, POST, PUT, PATCH e DELETE, eles cobrem 95% dos casos. HEAD e OPTIONS são complementos valiosos para otimização e descoberta. TRACE e CONNECT são mais específicos, usados em infraestrutura e debugging. Comece com a tríade GET/POST/DELETE e vá adicionando conforme a necessidade.

FAQ

Qual a diferença entre PUT e PATCH?

PUT substitui o recurso inteiro; PATCH altera apenas campos específicos. PUT é idempotente; PATCH pode não ser. Use PUT quando você envia o objeto completo; use PATCH para modificações pontuais.

GET pode ter corpo?

Tecnicamente, a especificação HTTP não proíbe, mas a prática padrão é que GET não tenha corpo. Servidores e proxies podem ignorar ou rejeitar corpos em GET. Prefira parâmetros na URL ou cabeçalhos.

O que significa idempotente em HTTP?

Uma requisição idempotente produz o mesmo efeito no servidor independentemente de quantas vezes for executada. GET, PUT, DELETE são idempotentes; POST não é.

Quando usar HEAD em vez de GET?

Use HEAD quando você só precisa dos cabeçalhos (tamanho, tipo, última modificação) sem baixar o corpo. Economiza banda e tempo em verificações de cache ou validação de recursos grandes.

POST pode ser idempotente?

Por padrão, não. Mas você pode implementar idempotência no servidor usando tokens de idempotência (enviados pelo cliente) para garantir que requisições repetidas não criem recursos duplicados.

O que é o método OPTIONS na prática?

OPTIONS retorna os métodos HTTP permitidos para um recurso. É usado por navegadores em requisições CORS (preflight) para verificar se o servidor aceita métodos como PUT ou DELETE antes de enviá-los.