Como aprendi HTTP de verdade sem estudar HTTP
Formação em redes me deu TCP/IP na veia. Mas HTTP como protocolo de aplicação — verbos, status codes, headers, idempotência — aprendi construindo API, não lendo RFC.
Formação em redes: TCP/IP, camadas OSI, ICMP, ARP, subnetting, OSPF. Sabia montar rede do zero.
HTTP eu usava mas não entendia de verdade.
Sabia que existia. Sabia que era na porta 80 ou 443. Sabia que tinha GET e POST. Mas não entendia o protocolo como ferramenta — o que cada verbo significa de verdade, por que status code importa, o que header controla.
Isso mudou quando comecei a construir API REST na POA Software e as coisas que eu construía quebravam de maneiras que eu não conseguia explicar.
O que formação em redes não te ensina sobre HTTP
Redes: você aprende o transporte. TCP garante entrega ordenada. IP roteia pacotes. TLS cifra o canal.
HTTP fica em cima disso tudo. É protocolo de aplicação — camada 7 no modelo OSI. E a camada 7 tem semântica que as outras não têm.
GET tem semântica. POST tem semântica. PUT tem semântica diferente de PATCH.
Quando comecei a construir API, usava POST para tudo. Precisava criar? POST. Precisava buscar? POST. Precisava atualizar? POST. Funcionava, mas estava jogando fora metade do protocolo.
O que cada verbo realmente significa
GET: busca recurso. Não modifica estado. Deve ser idempotente e seguro — você pode chamar 100 vezes que o resultado é o mesmo e nada muda no servidor. Browser pode cachear. Cliente pode retry sem medo.
POST: cria recurso ou envia dado para processamento. Não é idempotente — dois POSTs idênticos podem criar dois recursos. Browser não faz retry automático depois de POST com falha.
PUT: substitui recurso inteiro. Idempotente — PUT duas vezes com o mesmo corpo tem o mesmo resultado que PUT uma vez. Se o recurso não existe, cria.
PATCH: atualiza parcialmente. Só manda os campos que mudaram. Não idempotente por padrão (depende da implementação).
DELETE: remove recurso. Idempotente — deletar o que já foi deletado deve retornar 404, mas não causar erro de servidor.
Por que isso importa? Porque cliente e infraestrutura usam essa semântica. Proxy pode cachear GET. CDN pode cachear GET. Load balancer pode retry GET em falha. Se você usa POST para buscar dados, perde tudo isso.
Status codes — aprendi errando, não estudando. O que importa na prática: 200 para sucesso geral, 201 para POST que cria algo (sinaliza ao cliente que algo novo existe, diferente de 200), 204 para sucesso sem corpo de resposta (DELETE, operações que não retornam dado — não manda {} vazio com 200), 400 para erro do cliente (input inválido, campo obrigatório ausente), 401 para não autenticado (token ausente ou expirado), 403 para autenticado mas sem permissão, 404 para recurso que não existe, 409 para conflito de estado, 422 para input válido na estrutura mas inválido nas regras de negócio (email correto mas já cadastrado — 422, não 400), e 500 para erro do servidor.
Usar o status code certo não é estética. É semântica que o cliente usa para decidir o que fazer.
Headers que aprendi a respeitar: Content-Type diz ao servidor o que está sendo enviado — application/json vs application/x-www-form-urlencoded são lidos de forma diferente, errar quebra o parse silenciosamente. Authorization carrega token de autenticação — prefere header a query param para não vazar em logs. Cache-Control — no-cache não significa "não faz cache", significa "valida com servidor antes de usar cache"; no-store é "não armazena"; confundi isso por meses. ETag é identificador de versão do recurso — cliente manda ETag que tem, servidor responde 304 se não mudou.
O que background de rede ajudou
Quando aprendi que HTTP/2 multiplexa requisições em uma conexão TCP, entendi por que era melhor que HTTP/1.1 bundle otimizado. Conhecia o custo do TCP handshake.
Quando aprendi sobre TLS termination em load balancer, entendia o que estava acontecendo na camada 4 antes de chegar na camada 7.
Quando aprendi sobre Keep-Alive em HTTP, entendia por que reutilizar conexão TCP tem custo menor que abrir nova.
Background em redes não substituiu entender HTTP. Mas deu contexto que tornou o aprendizado mais rápido — os conceitos tinham âncoras.
O exercício que fechou o entendimento
Abre o DevTools no browser, vai na aba Network, carrega qualquer site com API, e passa 30 minutos lendo cada request:
- Que verbo foi usado?
- Que status code voltou?
- Que headers foram enviados e recebidos?
- Tem cache sendo usado?
Você vai ver HTTP real, não HTTP de tutorial. Vai ver status codes que nunca viu explicados. Vai ver headers que parecem estranhos até você pesquisar o que fazem.
Essa semana: faz isso. 30 minutos, qualquer site com API. Garanto que você vai encontrar algo que não sabia que existia.