HTTP e HTTPS

O que é

HTTP é um acordo sobre como dois programas conversam: um cliente envia um pedido em texto e um servidor devolve uma resposta. O navegador abrindo uma página, o aplicativo do celular buscando o saldo e um serviço chamando outro dentro do mesmo data center usam a mesma conversa.

O protocolo não guarda memória entre um pedido e o seguinte. Cada requisição precisa carregar tudo o que o servidor precisa para atendê-la, inclusive quem está pedindo. Essa característica se chama stateless, e é ela que permite colocar dez servidores idênticos atrás de um balanceador: qualquer um deles consegue responder a qualquer pedido.

Anatomia de uma requisição

Um pedido HTTP tem quatro partes:

POST /pedidos HTTP/1.1
Host: api.loja.com.br
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{"produto": 42, "quantidade": 2}

A resposta segue o mesmo desenho, trocando a primeira linha por um código de status:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /pedidos/981

{"id": 981, "status": "aguardando_pagamento"}

Métodos: a intenção do pedido

O método informa o que o cliente quer fazer, e também faz duas promessas que a infraestrutura leva a sério:

• Seguro: o pedido não altera nada no servidor.
• Idempotente: repetir o mesmo pedido deixa o servidor no mesmo estado que fazê-lo uma vez.

Essas promessas têm consequência prática. Um proxy, uma biblioteca de cliente ou o próprio navegador pode repetir sozinho um GET que falhou, porque repetir é inofensivo. Se o seu GET /pedidos/981/cancelar cancela o pedido, um robô de busca ou um pré-carregamento do navegador cancela pedidos por você.

Códigos de status: o resultado em três dígitos

O primeiro dígito define a família, e é ele que clientes, proxies e ferramentas de monitoramento olham primeiro.

A distinção entre 4xx e 5xx decide quem deve agir. Um 4xx diz ao cliente que repetir o mesmo pedido não adianta. Um 5xx diz que o problema é do servidor e que tentar mais tarde pode funcionar. Uma API que devolve 200 com {"erro": "..."} no corpo esconde a falha de todo o caminho: o balanceador acha que está saudável, o monitoramento não alerta e o cliente precisa abrir o corpo para descobrir.

Dois pares confundem bastante:

• 401 significa "não sei quem você é" (faltou ou venceu a credencial). 403 significa "sei quem você é, e você não pode".
• 502 e 504 vêm de um intermediário (proxy, balanceador) reclamando do serviço que está atrás dele. Quando aparecem, o problema quase nunca está no intermediário.

Cabeçalhos: onde mora o comportamento

O corpo carrega os dados; os cabeçalhos dizem como tratá-los. Os que você vai encontrar todo dia:

Como o protocolo não tem memória, é o par Cookie ou Authorization que reconstrói a identidade do usuário a cada pedido. Toda forma de login na web é uma variação disso.

O caminho de um pedido

Entre digitar um endereço e receber a resposta acontecem cinco etapas:

1. DNS: o nome api.loja.com.br é traduzido para um endereço IP.
2. Conexão TCP: cliente e servidor trocam três mensagens para abrir um canal confiável.
3. Negociação TLS (só no HTTPS): as duas pontas combinam as chaves de criptografia e o servidor prova quem é.
4. Requisição: o texto do pedido é enviado pelo canal.
5. Resposta: o servidor processa e devolve.

As três primeiras etapas custam tempo antes de qualquer dado útil trafegar. Por isso as conexões são reaproveitadas (keep-alive): depois da primeira resposta, o canal fica aberto para os próximos pedidos. Um serviço que abre uma conexão nova a cada chamada paga esse custo todas as vezes, e esse é um dos motivos mais comuns de lentidão entre serviços.

O que o HTTPS acrescenta

HTTPS é o mesmo HTTP trafegando dentro de um túnel TLS. O conteúdo da conversa não muda; o que muda são três garantias:

• Sigilo: quem está no meio do caminho (o Wi-Fi do café, o provedor) vê apenas com qual servidor você fala, e não o caminho, os cabeçalhos ou o corpo.
• Integridade: ninguém altera o conteúdo em trânsito sem que a conexão quebre.
• Autenticidade: o servidor apresenta um certificado, assinado por uma autoridade em que o seu sistema confia, provando que ele responde mesmo por aquele domínio.

Por que isso importa quando a IA escreve o código

Um assistente gera um endpoint funcional em segundos. O que ele não sabe é o contexto do seu sistema, e é nas decisões de protocolo que isso aparece:

• Ele escolhe POST para tudo ou GET para ações, se o pedido não disser a intenção.
• Ele devolve 200 com erro no corpo, ou 500 para um dado inválido do usuário.
• Ele escreve o cliente sem tempo limite, e um serviço lento trava o seu.
• Ele não sabe se uma operação pode ser repetida com segurança.

Quem entende o protocolo lê o código gerado e identifica esses pontos em um minuto. O nível seguinte compara as versões do HTTP e as formas de colocar HTTPS no ar.