Migrar uma API para um IP dedicado

Ao mudar de proxy residencial para IP dedicado, altera-se o endereço que o fornecedor da API vê. A mudança também pode afetar listas de permissões, assinaturas de pedidos, limites de taxa e novas tentativas. A forma mais segura de fazer a mudança é alterar o percurso de rede de um cliente de cada vez, mantendo as respetivas credenciais e o comportamento dos pedidos inalterados.

Este guia mostra como migrar uma API para um IP dedicado e aceder à API com segurança. Encare a mudança como uma alteração de rede, não apenas como uma atualização da configuração do proxy. Primeiro, identifique o cliente que envia os pedidos; depois, confirme as regras do fornecedor e teste o novo percurso antes de remover o antigo.

1. Identifique o percurso de saída do cliente de API

Comece por listar os clientes que chamam a API e onde cada um é executado. Um processo de produção, uma tarefa de preparação e um script local de um programador podem usar definições de proxy diferentes, mesmo que partilhem a mesma conta de API. Antes de fazer alterações, registe o ambiente de cada cliente, o local de implementação e o percurso de saída atual.

Em seguida, siga um pedido desde a aplicação até ao fornecedor. Verifique a biblioteca do cliente, as variáveis de ambiente, a configuração do proxy, as definições de rede do contentor ou do anfitrião e qualquer gateway de saída. A definição relevante é aquela que determina o endereço de origem visível para a API — não necessariamente a definição do proxy no ficheiro principal de configuração da aplicação.

Não inclua tráfego alheio à alteração. Se um anfitrião enviar pedidos para vários serviços, encaminhe apenas o cliente de API pelo IP dedicado, em vez de alterar o proxy de todo o anfitrião. Assim, limita o impacto de um erro: uma falha num pedido à API não deverá também interromper um agente de monitorização ou uma integração sem relação com a mudança.

Antes de editar a configuração atual, registe-a. Inclua o nome do cliente, o ambiente, o anfitrião de destino e a definição que controla o tráfego de saída. Uma nota breve facilita a comparação entre o percurso antigo e o novo quando um pedido falha.

2. Confirme os requisitos da lista de permissões de IP do fornecedor da API

Para saber como configurar a lista de permissões de IP de uma API, consulte a documentação da conta ou contacte o apoio ao cliente para conhecer as regras aplicáveis. Antes de encaminhar pedidos de produção, confirme o formato de endereço, o processo de aprovação e quando as alterações entram em vigor.

Confirme como o fornecedor aplica as regras da lista de permissões à conta e às chaves de API utilizadas. Se a conta tiver várias chaves de API, verifique se o endereço relevante tem de ser configurado para cada uma delas.

Pergunte se é possível manter o endereço atual do proxy residencial na lista de permissões enquanto testa o novo. Manter ambas as origens autorizadas evita uma mudança forçada enquanto verifica o novo percurso. Se o fornecedor exigir um pedido de aprovação ou uma janela de manutenção, planeie em função desse requisito, em vez de só o descobrir durante a implementação.

Se a conta de API tiver controlos de acesso rigorosos, compare o endereço esperado pelo fornecedor com o endereço atribuído ao IP dedicado. Confirme o endereço através do método documentado pelo fornecedor ou, se disponível, de um ponto final de teste seguro.

3. Adicione o IP dedicado sem remover a origem existente

Depois de o fornecedor confirmar o formato e o processo de aprovação, adicione o IP dedicado à lista de permissões da conta, mantendo a origem atual. Assim, cria uma janela de teste durante a qual pode usar qualquer um dos percursos. Guarde o registo da alteração, incluindo o endereço adicionado, a conta ou chave de API a que se aplica e o estado da aprovação.

Antes de enviar a alteração, verifique se há erros de formatação. Um erro de digitação, um intervalo não intencional ou uma entrada associada à conta errada podem gerar um resultado confuso: o novo cliente pode continuar a receber um erro de autorização, apesar de a lista de permissões parecer ter sido alterada. Se o processo do fornecedor o permitir, peça a outra pessoa que reveja o endereço.

Se o fornecedor da API disponibilizar contas de teste e de produção separadas, confirme a nova entrada na conta que o cliente realmente utiliza. Um teste bem-sucedido numa área de testes não confirma que a lista de permissões de produção foi atualizada. Registe claramente os nomes dessas contas nas notas da alteração.

Para a ligação ao proxy, utilize o método de autenticação documentado pelo fornecedor e não inclua credenciais no código-fonte. O guia de boas práticas de autenticação de proxies pode ajudar a verificar como o cliente fornece as credenciais do proxy sem as confundir com as credenciais da API.

4. Encaminhe um cliente de API pelo IP dedicado

Escolha um cliente de baixo risco para o primeiro teste, como um processo de preparação que envie pedidos representativos, mas não faça alterações visíveis para os clientes. Atualize apenas a configuração de saída desse cliente. Mantenha inalteradas a chave de API, os cabeçalhos dos pedidos, a construção dos dados enviados e as definições de tempo limite, para que o percurso de rede seja a principal variável.

Identifique claramente o novo percurso na configuração. Por exemplo, use uma variável de ambiente com um nome explícito ou um bloco de configuração separado para o cliente, em vez de substituir uma definição de proxy partilhada por várias aplicações. A definição exata depende do ambiente de execução e da biblioteca do cliente; antes da implementação, verifique como essa biblioteca gere proxies e ligações diretas.

Mantenha o percurso antigo disponível durante este teste. Reverter a alteração deve significar restaurar a definição de saída anterior do cliente, não voltar a criar as credenciais ou alterar o código dos pedidos à API. Não altere as credenciais.

Se o cliente utilizar um proxy HTTP ou SOCKS5 para chegar ao IP dedicado, confirme o protocolo e a porta com base nas instruções do fornecedor do proxy. As diferenças descritas neste guia sobre proxy SOCKS5 e proxy HTTP podem ser úteis se a biblioteca do cliente só for compatível com um dos protocolos. Confirme os requisitos efetivos da biblioteca antes de escolher.

5. Teste a autenticação da API e a assinatura dos pedidos

Envie um pequeno conjunto de pedidos representativos pelo IP dedicado. Inclua um pedido de leitura e, se a API permitir testes seguros, um pedido que utilize o mesmo processo de autenticação e assinatura do cliente de produção. Para a primeira verificação, use um ponto final que não provoque alterações; evite testar criando ou cancelando uma encomenda real.

Registe o código da resposta e o corpo da mensagem de erro do fornecedor. Um erro 401 ou 403 pode indicar um problema com as credenciais, as permissões ou uma regra de IP, mas a resposta do fornecedor é a referência final para identificar a causa. Se a API utilizar pedidos assinados, compare o método, o caminho, o carimbo temporal, o corpo e os cabeçalhos assinados exatos entre os percursos antigo e novo. Uma mudança no percurso de rede não deverá exigir uma nova assinatura, mas uma edição na configuração do cliente pode alterar acidentalmente a construção do pedido.

Se um pedido funcionar através do proxy residencial, mas falhar através do IP dedicado, verifique a lista de permissões da conta e as permissões associadas à chave. Siga a documentação do fornecedor para qualquer regra de acesso vinculada ao IP.

Mantenha separadas a autenticação do proxy e a autenticação da API. As credenciais do proxy autorizam o cliente a utilizá-lo; as credenciais da API autorizam o pedido ao serviço. Se os registos identificarem ambas as falhas apenas como «falha de autenticação», poderá perder tempo. Recolha detalhes suficientes para identificar em que ligação ou etapa do pedido ocorreu o erro.

6. Valide o comportamento da API com cargas de trabalho reais

Um único pedido bem-sucedido comprova a conectividade básica, não a preparação para produção. Execute o cliente selecionado com o padrão normal de pedidos e analise os códigos de resposta, a latência, os tempos limite e o comportamento das novas tentativas. Se o cliente enviar pedidos de leitura e de escrita, teste cada tipo de operação com registos seguros ou num ambiente de teste aprovado pelo fornecedor.

Esteja atento às respostas de limite de taxa. Confirme qual é o limite aplicável e como é determinado, em vez de presumir que o IP dedicado tem uma quota separada. Compare a forma como o cliente processa uma resposta de limite de taxa com as instruções do fornecedor, incluindo qualquer intervalo de espera ou cabeçalho de resposta obrigatório.

Antes de aumentar o tráfego, reveja as novas tentativas e a idempotência. Se um pedido atingir o fornecedor, mas exceder o tempo limite, uma nova tentativa automática pode repetir uma escrita, a menos que a API suporte uma chave de idempotência ou outro método de prevenção de duplicados. Teste esse comportamento com o mesmo padrão de pedidos utilizado pelo cliente em condições normais e confirme a resposta da API a um pedido repetido.

Verifique também os tempos limite de ligação e a reutilização de ligações. Um cliente que abra uma nova ligação para cada pedido pode comportar-se de forma diferente de outro que mantenha as ligações ativas, sobretudo quando há um proxy ou gateway no percurso. Registe separadamente as respostas de erro da própria API e os erros de DNS, de ligação e do proxy, para que a equipa possa identificar a camada que precisa de atenção.

7. Mude os restantes clientes e desative o percurso antigo

Depois de o primeiro cliente passar nas verificações, migre os restantes individualmente. Atualize um ambiente ou serviço de cada vez e confirme que os respetivos pedidos utilizam o IP dedicado e que a taxa de erros específicos da API se mantém dentro dos limites normais de funcionamento da equipa. Evite uma alteração global simultânea, pois torna mais difícil isolar as falhas.

Mantenha um registo simples das alterações, com o nome de cada cliente, a hora da implementação, o percurso e o resultado do teste. Se um cliente falhar, o registo ajuda a distinguir um problema de configuração específico do cliente de um problema geral com a lista de permissões do fornecedor. Suspenda a implementação até perceber a causa, em vez de aplicar a mesma alteração a mais ambientes.

Remova a origem do proxy residencial da lista de permissões apenas depois de confirmar que todos os clientes previstos estão a utilizar o IP dedicado e de terminar o período de reversão. Confirme com o fornecedor da API se a remoção de uma entrada exige aprovação ou produz efeitos imediatos. Depois de remover a entrada antiga, teste um pedido de cada ambiente migrado.

Guarde a configuração do percurso antigo num registo de reversão controlado, mas não mantenha o acesso não utilizado ativo sem motivo. Se uma implementação futura voltar a precisar do proxy residencial, solicite novamente o acesso através do processo normal de aprovação do fornecedor, em vez de depender de uma exceção não documentada.