HTTP, HTTPS e APIs

Depois que o TCP estabelece uma conexão confiável, as duas máquinas podem trocar bytes com segurança. No entanto, bytes brutos não têm significado inerente. Sem um protocolo compartilhado, o servidor não saberia se esses bytes representam uma solicitação de arquivo, envio de formulário ou algo totalmente diferente.

HTTP (Hypertext Transfer Protocol) define um formato estruturado para comunicação. Um cliente envia uma requisição (como GET /index.html), e o servidor retorna uma resposta contendo informações de status e dados.

HTTP padroniza como os recursos são solicitados, como os metadados são incluídos e como as respostas são formatadas. Isso torna a comunicação na web previsível e interoperável entre navegadores, servidores e plataformas.

Em resumo, o TCP garante a entrega. O HTTP garante o entendimento.

Uma requisição HTTP começa com uma request line. Ela inclui o método e o caminho. Por exemplo:
GET /users/123 HTTP/1.1
Isso informa ao servidor qual ação está sendo solicitada e qual recurso é o alvo.

O método comunica a intenção.

• GET recupera dados.
• POST envia novos dados.
• PUT atualiza dados existentes.
• DELETE remove dados.

Os headers fornecem contexto adicional, como o tipo de conteúdo (Content-Type), credenciais de autenticação (Authorization) ou informações sobre o cliente (User-Agent).

Por fim, algumas requisições incluem um body. Por exemplo, uma requisição POST pode incluir dados JSON sendo enviados ao servidor.

Juntos, esses componentes criam uma estrutura previsível que os servidores podem analisar e interpretar corretamente.

Uma resposta HTTP começa com uma linha de status, como:
HTTP/1.1 200 OK

O código de status comunica o resultado da solicitação.

• 200 significa sucesso.
• 404 significa que o recurso não foi encontrado.
• 500 indica um erro no lado do servidor.

Em seguida vêm os cabeçalhos, que fornecem metadados sobre a resposta. Eles podem incluir Content-Type (por exemplo, JSON ou HTML), Content-Length, regras de cache ou políticas de segurança.

Por fim, o corpo contém os dados reais solicitados — como uma página HTML, um objeto JSON ou um arquivo.

A estrutura da resposta garante que o cliente entenda tanto o que aconteceu quanto quais dados foram retornados.

HTTP é projetado como um protocolo sem estado. Isso significa que, quando um cliente envia uma requisição, o servidor a processa sem assumir qualquer contexto anterior.

Por exemplo, se você carregar uma página da web e depois clicar em um botão, a segunda requisição não inclui automaticamente a memória da primeira. Cada requisição deve conter todas as informações necessárias para o servidor processá-la.

A ausência de estado simplifica a escalabilidade. Como os servidores não dependem de estado de conexão armazenado, as requisições podem ser distribuídas entre várias máquinas atrás de um balanceador de carga.

Quando as aplicações precisam de continuidade — como sessões de login ou carrinhos de compras — elas implementam estado explicitamente usando cookies, identificadores de sessão ou tokens de autenticação.

HTTPS significa HTTP sobre TLS (Transport Layer Security). Em vez de enviar mensagens HTTP em texto simples, os dados são criptografados antes da transmissão.

Com HTTPS, tudo dentro da requisição e da resposta HTTP — incluindo headers e body — é criptografado. Isso impede que atacantes na rede leiam informações sensíveis, como senhas ou tokens.

O HTTPS também exige que o servidor apresente um certificado digital válido. O navegador verifica esse certificado com base em Autoridades Certificadoras confiáveis para confirmar a autenticidade do servidor.

Além disso, o TLS aplica verificações criptográficas de integridade para garantir que os dados não tenham sido modificados durante o trânsito.

Em resumo, o HTTPS protege a confidencialidade, a autenticidade e a integridade da comunicação na web.

Quando um cliente se conecta a um servidor HTTPS, o TLS primeiro realiza um handshake antes que qualquer dado HTTP seja enviado.

O processo começa com um Client Hello. O cliente propõe algoritmos criptográficos suportados (cipher suites) e envia dados aleatórios usados depois na geração de chaves.

O servidor responde com um Server Hello, selecionando os parâmetros de criptografia. Ele também envia seu certificado digital, que contém sua chave pública e é assinado por uma Certificate Authority confiável.

O cliente verifica o certificado e realiza um processo de key agreement (como Diffie-Hellman). Ambos os lados derivam independentemente o mesmo segredo compartilhado sem transmiti-lo diretamente.

Quando o handshake é concluído, chaves de criptografia simétrica são estabelecidas, e todo o tráfego HTTP subsequente é criptografado.

Um certificado digital é emitido por um terceiro confiável chamado Certificate Authority (CA). A CA verifica se a organização que solicita o certificado realmente controla o nome de domínio.

O certificado contém a chave pública do servidor, junto com informações de identificação sobre o domínio. Essa chave pública é usada durante o handshake do TLS para estabelecer comunicação criptografada.

Quando seu navegador se conecta a um site, ele verifica se o certificado foi assinado por uma CA em que ele já confia. Os navegadores vêm com uma lista integrada de Certificate Authorities confiáveis.

Se o certificado for válido, não estiver expirado e corresponder ao domínio solicitado, o navegador prossegue com a conexão segura. Caso contrário, ele exibe um aviso.

A confiança em HTTPS, portanto, é baseada em uma cadeia:
Você confia na CA → A CA confia no servidor → Você confia no servidor.

Uma API (Application Programming Interface) é uma especificação formal de como componentes de software interagem. Ela define quais operações estão disponíveis e como essas operações são acessadas.

Em sistemas web, as APIs normalmente usam HTTP. Os clientes enviam requisições para endpoints específicos (como /users/123) usando métodos definidos, como GET ou POST.

A API também define o formato da requisição esperado (por exemplo, JSON no corpo da requisição) e a estrutura do formato da resposta retornada pelo servidor.

Sem APIs, os sistemas dependeriam de convenções não documentadas ou de integrações fortemente acopladas. As APIs criam fronteiras claras, permitindo desenvolvimento independente, escalabilidade e interoperabilidade entre serviços.

REST (Representational State Transfer) organiza APIs em torno de recursos, não de ações. Um recurso é representado por uma URL como /users ou /orders/123.

Em vez de embutir verbos na URL, REST usa métodos HTTP para definir a operação:

• GET recupera dados.
• POST cria novos dados.
• PUT atualiza dados existentes.
• DELETE remove dados.

APIs REST são sem estado, o que significa que cada requisição contém todas as informações necessárias. O servidor não depende de requisições anteriores para processar a atual.

A maioria das APIs REST troca dados no formato JSON, que é leve, legível por humanos e facilmente interpretado por máquinas.

Essa estrutura torna as APIs REST consistentes, escaláveis e fáceis de entender em sistemas distribuídos.

Um erro 404 Não encontrado significa que o servidor está acessível, mas a rota ou o recurso solicitado não existe. Isso normalmente é um problema de roteamento na camada de aplicação.

Um 500 Erro interno do servidor indica que a requisição chegou ao servidor, mas algo falhou durante a execução — como uma falha, uma exceção não tratada ou uma falha de banco de dados.

Um erro Conexão recusada ocorre mais cedo na pilha. O cliente não consegue estabelecer uma conexão TCP, geralmente porque o servidor está fora do ar ou nenhum processo está escutando na porta de destino.

Um erro de certificado SSL acontece durante o handshake TLS se o certificado for inválido, expirado ou não corresponder ao domínio. O navegador bloqueia a conexão para proteger o usuário.

Um aviso de conteúdo misto aparece quando uma página HTTPS tenta carregar recursos HTTP. Isso quebra as garantias de segurança do HTTPS e é sinalizado pelos navegadores modernos.

Entender onde uma falha ocorre — na aplicação, no transporte ou no TLS — é fundamental para depuração eficaz.