O que é HTTP? Métodos, status e como a web conversa

Toda vez que você abre uma página, envia um formulário ou um app consome uma API, há um protocolo silencioso fazendo o trabalho pesado: o HTTP. Ele é a linguagem que navegadores e servidores usam para conversar. Neste artigo você vai entender o que é HTTP, como se estrutura uma requisição e uma resposta, o que significam os métodos e códigos de status que você vê o tempo todo, e ainda como cabeçalhos, cache, cookies e as novas versões do protocolo se encaixam nesse quebra-cabeça.

O que é HTTP

HTTP significa HyperText Transfer Protocol — Protocolo de Transferência de Hipertexto. É um conjunto de regras que define como um cliente (geralmente o navegador) e um servidor trocam mensagens. Sempre que você digita um endereço, o navegador monta uma requisição HTTP e a envia; o servidor processa e devolve uma resposta HTTP.

O HTTP segue um modelo simples de requisição-resposta: o cliente pergunta, o servidor responde, e a conexão para aquela troca se encerra. A semântica desse protocolo é formalmente descrita na RFC 9110: HTTP Semantics (Fielding, Nottingham, Reschke, 2022), que consolidou e atualizou especificações anteriores.

É importante separar duas coisas que costumam ser confundidas. O HTTP define a semântica — o que significa um GET, o que significa um status 404, o que cada cabeçalho representa. O transporte dessa semântica (como os bytes viajam pela rede) pode mudar entre versões sem alterar o significado das mensagens. É por isso que um desenvolvedor pode trabalhar a vida inteira pensando em "métodos e status" sem se preocupar se está rodando sobre HTTP/1.1 ou HTTP/3.

O HTTP é também um protocolo textual e legível por humanos na sua forma clássica. Você consegue ler uma requisição inteira e entender o que ela faz, o que torna o protocolo fácil de depurar com ferramentas simples — algo que veremos adiante.

Uma característica fundamental: sem estado

O HTTP é stateless (sem estado): cada requisição é independente e o servidor, por padrão, não lembra das requisições anteriores. Isso simplifica enormemente a arquitetura e permite escalar para milhões de usuários, mas cria um desafio — como manter você "logado" entre páginas?

A solução são mecanismos construídos por cima do HTTP, como cookies e tokens, que o cliente reenvia a cada requisição para que o servidor reconheça quem está pedindo. O protocolo em si permanece sem estado; o "estado" é simulado nessas camadas superiores.

Por que isso importa na prática? Porque a ausência de estado é o que permite distribuir o tráfego. Como nenhuma requisição depende de uma anterior estar na "memória" de um servidor específico, um balanceador de carga pode mandar cada requisição para uma máquina diferente sem quebrar nada. Se o HTTP guardasse estado por conexão, escalar horizontalmente seria muito mais difícil. Esse é um daqueles casos em que uma restrição aparentemente limitante se transforma em uma vantagem de arquitetura.

A anatomia de uma requisição

Uma requisição HTTP tem três partes principais:

GET /produtos/42 HTTP/1.1
Host: api.exemplo.com
Authorization: Bearer abc123
Accept: application/json

• A linha inicial traz o método (GET), o caminho (/produtos/42) e a versão.
• Os cabeçalhos carregam metadados: quem está pedindo, que formato aceita, credenciais.
• O corpo (opcional), presente em métodos como POST, carrega os dados enviados.

Os cabeçalhos são extremamente importantes: eles negociam formato, autenticação, cache e idioma, entre muitas outras coisas. O cabeçalho Host, por exemplo, é obrigatório no HTTP/1.1 porque um mesmo servidor pode hospedar vários sites no mesmo IP — é o Host que diz a qual deles a requisição se destina.

Vale notar que entre os cabeçalhos e o corpo existe uma linha em branco. Ela é o separador que diz ao servidor "acabaram os cabeçalhos, o que vem a seguir é o corpo". Esse detalhe parece trivial, mas é exatamente o que estrutura a mensagem em uma forma previsível para qualquer servidor.

A anatomia de uma resposta

A resposta do servidor espelha a estrutura da requisição:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600

{ "id": 42, "nome": "Teclado mecânico", "preco": 350 }

• A linha de status traz o código (200) e sua descrição (OK).
• Os cabeçalhos de resposta informam formato, regras de cache, e mais.
• O corpo carrega o conteúdo solicitado — uma página HTML, uma imagem ou dados em JSON.

A simetria entre requisição e resposta é proposital: ambas são "mensagens HTTP" com linha inicial, cabeçalhos, linha em branco e corpo. Aprender a estrutura de uma é aprender a estrutura da outra.

Os métodos HTTP

O método define a intenção da requisição. Os principais são:

• GET: solicita dados, sem causar efeitos colaterais. Deve ser seguro de repetir.
• POST: envia dados para criar um novo recurso ou disparar um processamento.
• PUT: substitui completamente um recurso existente.
• PATCH: atualiza parcialmente um recurso.
• DELETE: remove um recurso.

Além desses, existem métodos auxiliares importantes:

• HEAD: igual ao GET, mas o servidor responde apenas com os cabeçalhos, sem corpo. Útil para checar se um recurso existe ou se mudou, sem baixá-lo inteiro.
• OPTIONS: pergunta ao servidor quais métodos e capacidades estão disponíveis para um recurso. É a base do mecanismo de CORS, usado pelos navegadores para liberar requisições entre domínios diferentes.

Dois conceitos da RFC 9110 (Fielding, Nottingham, Reschke, 2022) merecem destaque. Métodos seguros (como GET e HEAD) não alteram o estado do servidor. Métodos idempotentes (GET, PUT, DELETE) produzem o mesmo efeito quando repetidos — útil para reenviar uma requisição após falha de rede sem medo de duplicar dados. Esse uso disciplinado dos métodos é o coração das APIs REST.

Idempotência na prática

A diferença entre POST e PUT ilustra bem a idempotência. Imagine que sua conexão caiu logo depois de enviar uma requisição, e você não sabe se ela chegou ao servidor. Se foi um PUT ("defina o usuário 42 com estes dados"), reenviar é seguro: o resultado final é idêntico, tenha o primeiro envio chegado ou não. Já um POST ("crie um novo pedido") não é idempotente: reenviar pode criar dois pedidos. Por isso APIs sérias costumam oferecer uma chave de idempotência (um cabeçalho com um identificador único) que permite ao servidor reconhecer e descartar reenvios de um mesmo POST. Entender essa distinção evita bugs sutis de duplicação em sistemas de pagamento e filas.

Os códigos de status

Os códigos de status são números de três dígitos que resumem o resultado da requisição. Eles se agrupam por faixa:

• 1xx — informativo: a requisição foi recebida e o processo continua (100 Continue, 101 Switching Protocols).
• 2xx — sucesso: 200 OK, 201 Created, 204 No Content.
• 3xx — redirecionamento: 301 Moved Permanently, 302 Found, 304 Not Modified.
• 4xx — erro do cliente: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests.
• 5xx — erro do servidor: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.

Memorizar as faixas já ajuda muito: se começa com 4, o problema foi do seu lado; se começa com 5, o servidor falhou. Esse vocabulário é a forma padronizada de comunicar resultados em qualquer API.

Os status que mais confundem

Alguns códigos merecem atenção porque são frequentemente mal usados:

• 401 vs 403: o 401 Unauthorized significa "não sei quem você é, autentique-se"; o 403 Forbidden significa "sei quem você é, mas você não tem permissão". Trocar um pelo outro confunde quem consome a API.
• 301 vs 302: o 301 Moved Permanently diz que o recurso mudou de endereço para sempre (e navegadores e buscadores memorizam isso); o 302 Found é um redirecionamento temporário. Usar 301 por engano em uma rota temporária pode "grudar" o redirecionamento no cache dos clientes.
• 304 Not Modified: não é erro. Ele diz "o recurso não mudou desde a última vez, use sua cópia em cache". É peça central do cache condicional.
• 204 No Content: sucesso, mas sem corpo na resposta. Comum em um DELETE ou em um PUT que não precisa devolver nada.

Escolher o status certo não é preciosismo: clientes, proxies, CDNs e buscadores tomam decisões automáticas com base nesse número.

Cabeçalhos: o sistema nervoso do HTTP

Se os métodos definem a intenção e os status resumem o resultado, os cabeçalhos são onde a maior parte da inteligência do HTTP acontece. Eles configuram comportamento sem mudar o corpo da mensagem. Alguns grupos importantes:

• Negociação de conteúdo: Accept, Accept-Language, Accept-Encoding. O cliente diz o que prefere receber (JSON ou HTML, português ou inglês, comprimido com gzip ou não) e o servidor escolhe a melhor resposta disponível.
• Autenticação: Authorization carrega credenciais, normalmente um token. O servidor pode responder com WWW-Authenticate para indicar como autenticar.
• Cache: Cache-Control, ETag, Last-Modified, Expires. São a base do desempenho da web, detalhados na próxima seção.
• Controle de conexão: Connection, Content-Length, Transfer-Encoding. Dizem como o corpo está delimitado e se a conexão deve ser reaproveitada.
• Segurança: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options. Instruem o navegador a aplicar políticas de proteção.

Um detalhe prático: cabeçalhos não diferenciam maiúsculas de minúsculas (Content-Type e content-type são equivalentes), e podem se repetir. Saber ler os cabeçalhos de uma resposta é metade do trabalho de depurar problemas de web.

Cache: por que a web é rápida

O HTTP tem um modelo de cache embutido que evita rebaixar a rede transferindo a mesma coisa repetidamente. Existem dois grandes mecanismos:

• Cache por tempo (fresh/stale): com Cache-Control: max-age=3600, o cliente sabe que pode reutilizar a resposta por uma hora sem nem perguntar ao servidor. Rápido, mas exige cuidado para não servir conteúdo velho.
• Cache condicional (revalidação): o servidor envia um ETag (uma "impressão digital" do conteúdo) ou um Last-Modified. Na próxima vez, o cliente pergunta "ainda é este ETag?" usando If-None-Match. Se nada mudou, o servidor responde 304 Not Modified sem corpo — economizando banda.

# Primeira resposta
HTTP/1.1 200 OK
ETag: "v3-9a1c"
Cache-Control: max-age=60

# Revalidação posterior
GET /produtos/42 HTTP/1.1
If-None-Match: "v3-9a1c"

# Resposta quando nada mudou
HTTP/1.1 304 Not Modified

Esse mecanismo é o que faz CDNs e navegadores entregarem conteúdo quase instantaneamente. Errar a configuração de cache é uma das causas mais comuns de bugs do tipo "atualizei o site mas o usuário ainda vê a versão antiga".

Cookies e o estado simulado

Como o HTTP é stateless, os cookies são a forma clássica de o servidor reconhecer um cliente entre requisições. O fluxo é direto:

# Servidor envia um cookie na resposta
HTTP/1.1 200 OK
Set-Cookie: sessao=abc123; HttpOnly; Secure; SameSite=Lax

# Cliente reenvia o cookie nas próximas requisições
GET /minha-conta HTTP/1.1
Cookie: sessao=abc123

Os atributos de um cookie são questões de segurança, não detalhes opcionais:

• HttpOnly: impede que JavaScript leia o cookie, mitigando roubo via XSS.
• Secure: o cookie só é enviado em conexões HTTPS.
• SameSite: controla se o cookie viaja em requisições vindas de outros sites, ajudando contra CSRF.

Esses cuidados só fazem sentido se a conexão for cifrada — afinal, um cookie de sessão trafegando em texto aberto pode ser interceptado, o que nos leva diretamente ao HTTPS.

A evolução do protocolo

O HTTP evoluiu bastante desde a versão clássica HTTP/1.1, definida originalmente na RFC 2616 (Fielding, Gettys, Mogul, et al., 1999). Essa versão estabeleceu conceitos que usamos até hoje, mas tinha limitações de performance, como abrir uma conexão por recurso e sofrer com o "bloqueio de cabeça de fila" (uma resposta lenta segurava as demais na mesma conexão).

Versões posteriores trouxeram ganhos importantes:

• HTTP/2 introduziu a multiplexação: várias requisições e respostas trafegam em paralelo numa única conexão, sem o bloqueio de fila do HTTP/1.1. Trouxe também compressão de cabeçalhos e o conceito de server push.
• HTTP/3 trocou o transporte TCP pelo QUIC, construído sobre UDP. Isso reduz a latência de estabelecimento de conexão e elimina o bloqueio de fila que ainda existia no nível do TCP, melhorando especialmente redes móveis instáveis.

Apesar dessas mudanças no "transporte", a semântica — métodos, status, cabeçalhos — permaneceu estável, justamente o que a RFC 9110 (Fielding, Nottingham, Reschke, 2022) consolidou de forma independente da versão. Na prática, isso significa que seu código de aplicação raramente precisa saber qual versão está em uso: o ganho de performance vem "de graça" na camada de transporte.

HTTP versus HTTPS

O HTTP puro envia dados em texto aberto, o que significa que qualquer um no caminho da rede pode lê-los ou alterá-los. Para resolver isso, existe o HTTPS, que envolve o HTTP em uma camada de criptografia. Hoje, usar HTTPS não é opcional: navegadores marcam sites HTTP como inseguros. Entenda essa diferença em O que é HTTPS? A versão segura do HTTP, e a tecnologia de criptografia por trás dela em O que é TLS? Como o HTTPS protege suas conexões.

Antes do HTTP: encontrar o servidor

Há um passo que acontece antes da primeira requisição HTTP. Quando você digita um endereço como exemplo.com, o computador precisa descobrir o número de IP por trás daquele nome. Esse é o trabalho do DNS, que traduz nomes legíveis em endereços de rede. Para entender essa etapa, veja O que é DNS? A agenda telefônica da internet. Só depois de resolver o nome o navegador consegue abrir a conexão e enviar a requisição HTTP.

Como inspecionar HTTP na prática

Saber a teoria é metade do caminho; a outra metade é conseguir observar o HTTP acontecendo. Algumas ferramentas essenciais:

• DevTools do navegador (aba Network): mostra cada requisição, seus cabeçalhos, status, tempo e corpo. É o lugar onde a maioria dos problemas de front-end é diagnosticada.
• curl: a ferramenta de linha de comando para falar HTTP manualmente. O exemplo abaixo mostra os cabeçalhos de resposta de uma API:

curl -i -X GET https://api.exemplo.com/produtos/42 \
  -H "Authorization: Bearer abc123" \
  -H "Accept: application/json"

A opção -i inclui a linha de status e os cabeçalhos na saída; -X define o método; cada -H adiciona um cabeçalho. Trocar GET por POST e adicionar -d '{"nome":"X"}' envia um corpo. Dominar o curl é dominar o HTTP cru, sem a mediação de bibliotecas.

Erros comuns ao trabalhar com HTTP

• Usar GET para causar efeitos colaterais. Como GET é seguro e cacheável, um navegador ou proxy pode repeti-lo sem aviso. Um link que apaga algo via GET pode ser disparado por um pré-carregador de página.
• Ignorar a idempotência em retentativas. Reenviar um POST cegamente após timeout pode duplicar pedidos ou cobranças.
• Devolver 200 para erros. Responder 200 OK com um corpo {"erro": "não encontrado"} quebra clientes, caches e monitoramento, que confiam no código de status. Use o status correto.
• Configurar cache errado. Cache agressivo demais serve conteúdo velho; cache de menos joga fora desempenho.
• Esquecer o Content-Type. Enviar JSON sem declarar application/json faz muitos servidores e clientes interpretarem mal o corpo.

Perguntas frequentes

HTTP e HTML são a mesma coisa? Não. HTTP é o protocolo que transporta mensagens; HTML é uma linguagem de marcação que costuma vir dentro do corpo dessas mensagens. O HTTP transporta HTML, mas também JSON, imagens, vídeos e qualquer outro tipo de dado.

Qual a diferença entre HTTP e uma API? O HTTP é o protocolo de transporte. Uma API web é um contrato de uso construído sobre o HTTP, definindo quais rotas, métodos e formatos um sistema expõe. APIs no estilo REST usam a semântica do HTTP de forma disciplinada.

Preciso decorar todos os códigos de status? Não. Decore as faixas (2xx sucesso, 4xx erro do cliente, 5xx erro do servidor) e um punhado dos mais comuns (200, 201, 204, 301, 304, 400, 401, 403, 404, 429, 500, 503). O resto você consulta quando precisar.

O HTTP/2 e o HTTP/3 mudam meu código? Quase nunca. Eles mudam como os bytes viajam, não a semântica. Você ativa essas versões no servidor ou na CDN e ganha performance sem reescrever a aplicação.

Conclusão

O HTTP é o protocolo que faz a web conversar: um ciclo simples de requisição e resposta, organizado por métodos que expressam intenção e códigos de status que resumem resultados. Em volta desse núcleo orbitam cabeçalhos que negociam formato e segurança, um modelo de cache que torna a web rápida e cookies que simulam estado sobre um protocolo sem memória. Apesar de o transporte ter evoluído do HTTP/1.1 ao HTTP/3, sua semântica permanece a mesma e continua sendo conhecimento essencial para qualquer desenvolvedor web. Entender HTTP — e saber inspecioná-lo com DevTools e curl — é entender a gramática básica da internet.

Referências

• Fielding, Nottingham, Reschke (2022). RFC 9110: HTTP Semantics. IETF.
• Fielding, Gettys, Mogul, et al. (1999). RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. IETF.
• Belshe, M., Peon, R., Thomson, M. (2015). RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2). IETF.
• Bishop, M. (2022). RFC 9114: HTTP/3. IETF.