Protocolo HTTP

Este material complementa os slides do Tópico 09 e aprofunda o funcionamento do HTTP, o principal protocolo de aplicação da Web moderna.

Entender HTTP é essencial para qualquer pessoa que desenvolve backend, porque APIs, navegadores, aplicações mobile, proxies, gateways e microsserviços dependem diretamente desse modelo de comunicação.

1. Onde o HTTP se encaixa?

O HTTP não atua sozinho. Ele funciona sobre outras camadas e protocolos da pilha de rede.

Alguns componentes importantes:

IP: responsável pelo endereçamento e roteamento de pacotes;
TCP: fornece comunicação confiável, ordenada e orientada a conexão;
DNS: traduz nomes de domínio em endereços IP;
TLS: adiciona segurança criptográfica quando usamos HTTPS;
HTTP: define a forma como cliente e servidor trocam mensagens de aplicação.

Em termos simples:

o cliente descobre o endereço do servidor usando DNS;
estabelece uma conexão de transporte;
envia uma requisição HTTP;
recebe uma resposta HTTP.

2. TCP, IP e DNS no contexto da Web

2.1 IP

O IP cuida do endereçamento lógico e do roteamento dos pacotes entre redes.

Exemplo conceitual:

exemplo.com -> 203.0.113.10

2.2 TCP

O TCP é muito importante para HTTP/1.1 e HTTP/2 porque garante:

entrega confiável;
ordenação dos dados;
controle de retransmissão;
comunicação orientada a conexão.

2.3 DNS

O DNS converte nomes legíveis por humanos em endereços que podem ser usados pela rede.

Sem DNS, em vez de digitar api.exemplo.com, precisaríamos memorizar IPs numéricos.

3. O que é HTTP?

O HyperText Transfer Protocol é um protocolo de aplicação baseado no modelo requisição-resposta.

Características centrais:

comunicação entre cliente e servidor;
mensagens textuais em HTTP/1.x e binárias em HTTP/2;
protocolo stateless, ou seja, cada requisição é independente por definição;
uso comum das portas 80 para HTTP e 443 para HTTPS.

Ser stateless não significa que aplicações não possam manter estado. Sessões, tokens e cookies existem justamente para reconstruir contexto entre requisições independentes.

4. Estrutura de uma requisição HTTP

Uma requisição HTTP costuma ter:

linha inicial;
cabeçalhos;
linha em branco;
corpo, quando necessário.

Exemplo:

POST /login HTTP/1.1
Host: exemplo.com
Content-Type: application/json
Content-Length: 39

{"user":"teste","password":"123456"}

Partes principais:

POST: método HTTP;
/login: caminho do recurso;
HTTP/1.1: versão do protocolo;
cabeçalhos: metadados sobre a mensagem;
corpo: dados enviados ao servidor.

5. Estrutura de uma resposta HTTP

Uma resposta segue a mesma ideia geral: linha inicial, cabeçalhos e corpo.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 38
Date: Fri, 06 Aug 2030 01:31:51 GMT

<html><body>Ola Mundo!</body></html>

Elementos principais:

HTTP/1.1: versão da resposta;
200 OK: código e mensagem de status;
cabeçalhos: informações sobre o conteúdo e a resposta;
corpo: payload devolvido ao cliente.

6. Métodos HTTP

Os métodos indicam a intenção da operação.

Os mais comuns em APIs:

GET: obter dados;
POST: criar ou processar algo;
PUT: substituir completamente um recurso;
PATCH: atualizar parcialmente;
DELETE: remover;
HEAD: obter apenas metadados;
OPTIONS: descobrir capacidades do endpoint.

Em design de APIs REST, escolher corretamente o método ajuda a tornar o contrato mais previsível.

6.1 Métodos seguros e idempotentes

Dois conceitos importantes ao trabalhar com HTTP:

método seguro: não deve alterar o estado do servidor;
método idempotente: repetir a mesma requisição produz o mesmo efeito observável no servidor.

Exemplos:

GET, HEAD e OPTIONS são considerados seguros;
GET, PUT e DELETE são normalmente tratados como idempotentes;
POST geralmente não é idempotente, porque pode criar novos recursos a cada envio.

Esses conceitos ajudam a definir comportamento esperado de clientes, proxies, caches e mecanismos de retry.

7. Códigos de status

Os códigos de status indicam o resultado da operação.

7.1 Faixas principais

1xx: respostas informativas;
2xx: sucesso;
3xx: redirecionamento;
4xx: erro do cliente;
5xx: erro do servidor.

7.2 Exemplos frequentes

200 OK: sucesso com resposta;
201 Created: recurso criado;
204 No Content: sucesso sem corpo;
400 Bad Request: requisição inválida;
401 Unauthorized: autenticação necessária ou inválida;
403 Forbidden: acesso negado;
404 Not Found: recurso não encontrado;
500 Internal Server Error: erro inesperado no servidor.

7.3 Diferença entre `401` e `403`

Esses dois códigos costumam gerar confusão:

401 Unauthorized: o cliente não enviou credenciais válidas ou ainda precisa se autenticar;
403 Forbidden: o cliente foi identificado, mas não tem permissão para acessar o recurso.

Exemplos típicos:

token ausente, expirado ou inválido -> 401;
usuário autenticado tentando acessar uma área administrativa sem permissão -> 403.

8. Cabeçalhos HTTP comuns

Cabeçalhos carregam metadados importantes sobre requisição e resposta.

8.1 Cabeçalhos de requisição

Host: domínio de destino;
User-Agent: identifica o cliente;
Accept: formatos aceitos pelo cliente;
Authorization: credenciais ou token;
Cookie: dados enviados pelo cliente;
Connection: controle de persistência da conexão.

8.2 Cabeçalhos de resposta

Content-Type: tipo do corpo devolvido;
Content-Length: tamanho do corpo em bytes;
Date: data da resposta;
Cache-Control: política de cache;
Last-Modified: última modificação do recurso;
Set-Cookie: instruções para o cliente armazenar cookies.

9. Tipos de conteúdo

O cabeçalho Content-Type informa como interpretar o corpo da mensagem.

Exemplos frequentes:

text/plain;
text/html;
application/json;
application/xml;
multipart/form-data;
application/octet-stream;
image/png;
audio/mpeg;
video/mp4.

Esse detalhe é importante porque o mesmo protocolo pode transportar HTML, JSON, imagens, áudio e arquivos binários.

9.1 `Content-Type` x `Accept`

Dois cabeçalhos relacionados, mas com papéis diferentes:

Content-Type: informa o formato do corpo que está sendo enviado;
Accept: informa quais formatos o cliente deseja receber.

Exemplo de requisição:

GET /produtos HTTP/1.1
Host: api.exemplo.com
Accept: application/json

Exemplo de resposta:

HTTP/1.1 200 OK
Content-Type: application/json

Essa distinção é importante para negociação de conteúdo entre cliente e servidor.

10. Stateless, cookies e sessão

O HTTP é descrito como stateless porque, conceitualmente, cada requisição é independente das anteriores.

Mesmo assim, aplicações frequentemente precisam lembrar contexto, como:

usuário autenticado;
itens do carrinho;
preferências de interface.

Isso costuma ser feito com:

cookies;
identificadores de sessão;
tokens, como JWT;
armazenamento de estado do lado do servidor.

11. Conexão e Keep-Alive

Antes de trocar mensagens HTTP, cliente e servidor precisam estabelecer a conexão de transporte correspondente.

No HTTP/1.1, conexões persistentes se tornaram padrão, permitindo múltiplas requisições na mesma conexão TCP. Isso reduz custo de abertura e fechamento repetidos.

Cabeçalho comum:

Connection: keep-alive

Esse reaproveitamento ajuda a reduzir latência, especialmente em páginas com muitos recursos.

12. Cache HTTP com `ETag` e `Cache-Control`

O protocolo HTTP possui mecanismos importantes de cache, que ajudam a reduzir latência, consumo de banda e carga no servidor.

12.1 `Cache-Control`

Define políticas sobre como a resposta pode ser armazenada e reutilizada.

Exemplo:

Cache-Control: max-age=3600

Isso indica que a resposta pode ser reutilizada por até 3600 segundos.

12.2 `ETag`

O ETag funciona como um identificador de versão de um recurso.

Exemplo:

ETag: "produto-10-v3"

Se o cliente já tiver uma versão antiga em cache, pode enviar uma requisição condicional para verificar se houve mudança.

Essa estratégia evita transferências desnecessárias quando o conteúdo ainda não foi alterado.

13. Comparação entre versões HTTP

13.1 HTTP/1.0

Popularizou o protocolo, mas com limitações importantes:

menor eficiência;
conexões normalmente não persistentes por padrão;
menos padronização de recursos em relação às versões posteriores.

13.2 HTTP/1.1

Por muitos anos foi a versão dominante.

Melhorias importantes:

conexões persistentes;
cabeçalho Host obrigatório;
melhor uso de cache;
suporte mais amplo a métodos e códigos.

13.3 HTTP/2

O HTTP/2 trouxe otimizações de transporte na camada de aplicação:

protocolo binário;
multiplexação de múltiplos streams;
compressão de cabeçalhos;
melhor aproveitamento de uma mesma conexão.

Ele reduz overhead, embora ainda dependa do transporte subjacente para lidar com perdas de pacote.

O chamado Server Push fez parte da proposta do HTTP/2, mas teve adoção prática limitada e perdeu relevância em muitos ambientes modernos. Por isso, hoje ele costuma ser tratado mais como contexto histórico do que como recurso central do protocolo.

13.4 HTTP/3

O HTTP/3 usa QUIC, que opera sobre UDP, trazendo melhorias relevantes:

menor latência de conexão;
multiplexação sem o mesmo tipo de bloqueio observado sobre TCP;
recuperação mais eficiente em cenários de perda;
integração com mecanismos modernos de segurança.

14. HTTPS e TLS

O HTTPS é a versão segura do HTTP, executada sobre TLS.

Ele protege a comunicação com:

criptografia;
verificação de integridade;
autenticação do servidor por certificado digital.

Em conexões HTTPS, o cliente valida o certificado apresentado pelo servidor e negocia parâmetros criptográficos antes de trocar dados da aplicação.

Hoje, HTTPS é requisito básico para:

login;
APIs autenticadas;
pagamentos;
qualquer troca de dados sensíveis.

15. Exemplo prático completo

Requisição:

GET /api/produtos/10 HTTP/1.1
Host: api.exemplo.com
Accept: application/json
Authorization: Bearer <token>

Resposta:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache

{
  "id": 10,
  "nome": "Teclado",
  "preco": 199.90
}

Nesse exemplo, a mesma mensagem HTTP carrega método, rota, autenticação, formato esperado, status e dados do recurso solicitado.

16. Boas práticas ao trabalhar com HTTP

Escolher o método HTTP adequado para a intenção da operação.
Retornar códigos de status coerentes.
Definir Content-Type corretamente.
Evitar expor dados sensíveis em URLs.
Usar HTTPS em ambientes reais.
Projetar APIs previsíveis, consistentes e bem documentadas.

17. Conclusão

Neste tópico você viu que o HTTP é muito mais do que “abrir uma página no navegador”. Ele define um contrato completo de comunicação entre clientes e servidores, incluindo métodos, cabeçalhos, códigos de status, corpo da mensagem, persistência de conexão e segurança com HTTPS.

Compreender HTTP torna muito mais fácil construir APIs, depurar problemas de integração, interpretar logs e tomar decisões corretas de design em aplicações backend.

18. Materiais de apoio

MDN Web Docs - HTTP: https://developer.mozilla.org/en-US/docs/Web/HTTP
HTTP Semantics (RFC 9110): https://www.rfc-editor.org/rfc/rfc9110
HTTP Caching (MDN): https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
QUIC and HTTP/3 Overview: https://http3-explained.haxx.se/

Protocolo HTTP

1. Onde o HTTP se encaixa?

2. TCP, IP e DNS no contexto da Web

2.1 IP

2.2 TCP

2.3 DNS

3. O que é HTTP?

4. Estrutura de uma requisição HTTP

5. Estrutura de uma resposta HTTP

6. Métodos HTTP

6.1 Métodos seguros e idempotentes

7. Códigos de status

7.1 Faixas principais

7.2 Exemplos frequentes

7.3 Diferença entre 401 e 403

8. Cabeçalhos HTTP comuns

8.1 Cabeçalhos de requisição

8.2 Cabeçalhos de resposta

9. Tipos de conteúdo

9.1 Content-Type x Accept

10. Stateless, cookies e sessão

11. Conexão e Keep-Alive

12. Cache HTTP com ETag e Cache-Control

12.1 Cache-Control

12.2 ETag

13. Comparação entre versões HTTP

13.1 HTTP/1.0

13.2 HTTP/1.1

13.3 HTTP/2

13.4 HTTP/3

14. HTTPS e TLS

15. Exemplo prático completo

16. Boas práticas ao trabalhar com HTTP

17. Conclusão

18. Materiais de apoio

7.3 Diferença entre `401` e `403`

9.1 `Content-Type` x `Accept`

12. Cache HTTP com `ETag` e `Cache-Control`

12.1 `Cache-Control`

12.2 `ETag`