As respostas de sucesso recebem a maior parte da atenção em uma migração, já que são o que uma demonstração mostra e o que uma primeira rodada de testes costuma verificar. As respostas de erro recebem muito menos atenção, e isso está exatamente ao contrário, porque o código de tratamento de erros muitas vezes é o que quebra primeiro, e de forma mais visível, em produção quando um provedor muda por baixo de uma aplicação.
Cada provedor de geocodificação e de dados de localização tem suas próprias convenções para sinalizar falhas: alguns usam exclusivamente códigos de status HTTP, alguns incluem um campo de status dentro de uma resposta JSON que, fora isso, tem status 200, alguns distinguem entre "nenhum resultado encontrado" e "requisição inválida" com códigos diferentes, e alguns juntam os dois em um erro genérico. A lógica de novas tentativas de uma aplicação, as mensagens de erro exibidas ao usuário e os alertas de monitoramento costumam ser construídos em torno das convenções de erro de um provedor específico, às vezes sem que ninguém documente essa dependência explicitamente.
Antes de trocar de provedor, vale a pena montar uma tabela de mapeamento explícita entre as respostas de erro do provedor antigo e as do novo, cobrindo no mínimo:
O My Geocode documenta suas respostas de erro e convenções de status em /docs/errors/, e toda resposta também traz cabeçalhos de cota, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit e X-Quota-Reset, que cobrem uma categoria de informação, o status de cota e de limite de taxa, que alguns provedores escondem dentro do corpo das respostas de erro em vez de expor diretamente nos cabeçalhos. Verificar se a sua lógica atual de novas tentativas lê as informações de cota do corpo da resposta ou de um cabeçalho é um bom item específico para acrescentar a uma checklist de migração, já que informações de cota em cabeçalhos geralmente são mais fáceis de ler sem mexer no caminho de parsing da resposta usado para os dados propriamente ditos.
Uma forma prática de montar a tabela de mapeamento é provocar deliberadamente cada condição de erro no provedor antigo e no novo, em um ambiente de teste, em vez de confiar apenas na documentação, já que documentação e comportamento real nem sempre coincidem exatamente, em nenhum provedor. Envie uma requisição malformada, esgote de propósito uma pequena cota de teste e envie uma chave inválida, depois registre exatamente o que cada provedor retorna em cada caso.
Esse tipo de trabalho de mapeamento de erros raramente aparece no plano de projeto de uma migração, porque não produz um recurso visível, mas tem um peso desproporcional na forma como a migração é lembrada depois. Uma migração que altera as respostas de sucesso de forma limpa, mas deixa o tratamento de erros quebrado, costuma gerar muito mais chamados de suporte nas primeiras semanas após a virada do que uma que acertou só em parte o caminho feliz.