Muitas integrações de geocodificação e de dados de localização nem se comunicam diretamente com uma API HTTP; elas passam por uma biblioteca cliente oficial ou um SDK que encapsula as requisições, cuida da autenticação e retorna os resultados como objetos tipados na linguagem em que a aplicação foi escrita. Essa camada extra é conveniente no dia a dia, mas acrescenta uma complicação real a uma migração, porque a própria biblioteca, e não apenas a API por trás dela, precisa fazer parte do plano.
De modo geral, há três caminhos que uma migração envolvendo uma biblioteca cliente costuma seguir, e vale a pena decidir qual deles se aplica antes de começar:
A biblioteca aceita uma URL base personalizada. Algumas bibliotecas cliente oficiais são escritas de forma flexível o bastante para aceitar uma URL base diferente para as requisições, mantendo o restante da interface inalterado. Nesse caso, apontar a biblioteca existente para um host de compatibilidade, se o formato da resposta corresponder ao que a biblioteca espera interpretar, pode funcionar praticamente sem nenhuma mudança no código da aplicação. Esse é o melhor cenário e vale a pena verificá-lo primeiro.
A biblioteca está fortemente acoplada a um único host. Muitas bibliotecas cliente fixam no código o host de destino ou fazem suposições específicas do fluxo de autenticação do seu provedor que não podem ser facilmente redirecionadas. Nesse caso, o caminho pragmático geralmente é contornar a biblioteca por completo nas chamadas migradas e fazer as requisições diretamente na API do novo provedor, substituindo o wrapper tipado da biblioteca por uma função de requisição enxuta sua.
Nenhuma biblioteca está envolvida. Se a sua integração já faz requisições HTTP diretas sem uma biblioteca oficial no meio, toda essa questão não se aplica, e a migração é uma questão mais direta de trocar o host, a chave e qualquer interpretação das respostas que precise de ajuste.
Como a autenticação da My Geocode aceita um cabeçalho X-API-Key, um cabeçalho Authorization: Bearer, HTTP Basic auth ou um parâmetro de consulta, uma biblioteca cliente que já se autentica de qualquer uma dessas formas comuns tem uma chance razoável de funcionar com um host de compatibilidade apenas com a troca da URL base e uma nova chave, mesmo sem suporte oficial de biblioteca própria para esta plataforma específica. Vale a pena testar isso diretamente em um ambiente de staging antes de supor que vai funcionar sem mudanças ou que não vai funcionar de jeito nenhum; o resultado real depende inteiramente de quão flexível é a forma como a biblioteca em questão foi escrita.
Qualquer que seja o caminho, vale a pena documentar a decisão explicitamente nas suas notas de migração, já que uma dependência de biblioteca que é contornada silenciosamente durante uma migração, mas não documentada, costuma confundir quem mantém o código um ano depois, quando atualiza a biblioteca antiga esperando que ela ainda esteja no caminho das requisições. Um comentário curto explicando que as requisições agora contornam a biblioteca cliente oficial, e por quê, evita uma confusão real mais adiante.