HTTP e HTTPS: o transporte das APIs

Uma chamada de integração precisa levar a solicitação até o serviço e trazer a resposta de volta. A maior parte das APIs remotas usa o HTTP para organizar essa troca e o HTTPS para protegê-la no caminho. Saber como essa troca acontece ajuda a localizar em qual etapa uma chamada falhou.

Requisição e resposta

O HTTP é um protocolo de requisição e resposta, o mesmo usado pelos navegadores para abrir sites. O cliente envia uma requisição, que informa a operação desejada e, quando necessário, os dados da operação. O servidor devolve uma resposta, com um código de situação, informações de controle e, quando há, um conteúdo. Nas integrações, o cliente é um programa, como o sistema da loja ou o integrador do site de vendas.

Interfaces organizadas de formas diferentes, como REST e SOAP, podem usar o mesmo HTTP para transportar as mensagens. O transporte comum não torna iguais as operações, os contratos ou os formatos dessas interfaces.

A porta padrão do HTTP é a 80, e a do HTTPS é a 443. Um serviço pode usar outra porta, indicada no endereço depois do nome, como em https://api.example.com:8443.

O HTTPS e o TLS

O HTTPS é o HTTP protegido pelo TLS, o protocolo que criptografa a comunicação e permite verificar a identidade do serviço. Antes de trocar as mensagens HTTP, o cliente confere o certificado apresentado pelo serviço, e os dois lados combinam a proteção da conexão. Algumas integrações, como as de bancos e as fiscais, exigem também um certificado do cliente. Essa forma, em que os dois lados apresentam certificados, se chama mTLS.

Uma chamada HTTPS passa por quatro etapas, nesta ordem:

1. a tradução do nome do serviço em endereço IP, pelo DNS;
2. a abertura da conexão TCP com a porta do serviço;
3. a negociação TLS, com a verificação do certificado;
4. a troca da requisição e da resposta HTTP.

Essa sequência vale para as versões 1.1 e 2 do HTTP. A versão 3 usa outro transporte, sobre UDP, e não segue a mesma sequência.

Cada requisição é independente

O HTTP não guarda memória entre uma requisição e outra, e o serviço não reconhece, pela mensagem, quem fez a requisição anterior. Quando a aplicação precisa reconhecer quem chama, ela exige uma credencial em cada requisição, como um token, um código temporário entregue pelo serviço depois da identificação do programa. Outra forma é a sessão, com um identificador que o cliente apresenta a cada requisição.

Por isso, em uma integração que exige token, cada chamada protegida apresenta o token novamente. Nem toda requisição HTTP tem token. Há operações públicas e outras formas de identificação, como os certificados.

O que a conexão protegida não comprova

O TLS protege a comunicação entre os dois participantes de uma conexão. Quando um intermediário, como um proxy da rede, encerra a conexão protegida e abre outra até o serviço, existem dois trechos protegidos e duas verificações de certificado. Nesse caso, o certificado que o programa recebe pode ser o do intermediário, e não o do serviço.

Uma conexão TLS estabelecida não confirma que a credencial foi aceita, que os dados estavam corretos ou que a operação foi concluída. Essas verificações acontecem nas etapas seguintes. Desligar a verificação do certificado para fazer uma falha desaparecer não resolve o problema e deixa a comunicação exposta. A mensagem de erro indica o que conferir: a confiança no emissor do certificado, o nome, a validade ou a compatibilidade da negociação.