O HERE Geocoding and Search aparece muito em software automotivo e de logística, setores em que uma conta corporativa com um contato designado e um contrato de suporte é a forma normal de fazer negócios. A autenticação geralmente é uma chave de API ou um token OAuth, e as respostas vêm como um array items, em que cada item traz um objeto position e um bloco estruturado address com campos como label, countryCode e houseNumber.
Essa estrutura costuma ser bem documentada internamente nas empresas que dependem dela, porque o HERE muitas vezes é escolhido especificamente pela qualidade do parsing de endereços em uma determinada região ou pela integração de rotas em outra parte da stack. Uma migração que quebra o formato da resposta quebra todo esse código dependente de uma só vez, e é por isso que a compatibilidade importa mais aqui do que o custo de trocar a conta em si.
O host de compatibilidade com o HERE do My Geocode reproduz o array items e seus campos aninhados position e address exatamente como o HERE os retorna, substituindo apenas o texto de copyright, termos e privacidade. Veja /compatibility/here/ para a referência dos campos. Na maioria dos casos, a mudança necessária no código da aplicação é o nome do host e a chave, e nada no código que lê items[0].position ou items[0].address.label.
Equipes corporativas que migram do HERE muitas vezes têm a geocodificação integrada em vários serviços, e não em um só, então ajuda fazer primeiro um inventário de todos os pontos de chamada: processamentos em lote, formulários de validação de endereços, roteamento de entregas e qualquer ferramenta administrativa tendem a acessar a mesma API de forma independente. Migrá-los um serviço por vez, começando por algo de pouco tráfego, é uma forma sensata de validar o novo host em condições reais antes que as chamadas de maior volume sejam trocadas.
Quanto à autenticação, uma chave emitida pelo My Geocode pode ser enviada como cabeçalho X-API-Key, cabeçalho Authorization: Bearer, autenticação HTTP Basic ou parâmetro de consulta. Se a sua biblioteca cliente atual do HERE já se autentica de uma forma específica, apontá-la para o novo host com uma nova chave geralmente basta, já que a biblioteca em si não precisa mudar.
Os preços eliminam uma camada de negociação que os contratos corporativos costumam ter. Não há uma estrutura de conta em níveis: 2.500 requisições por dia são gratuitas sem chave, cada chave acrescenta mais 2.500 requisições gratuitas por dia contadas por rede e, acima disso, é crédito pré-pago a € 0,0001 por requisição ou uma chave Unlimited a € 50 por mês. Todos os endpoints, incluindo este host de compatibilidade, custam o mesmo, então não há uma negociação separada para o volume de geocodificação e o volume de busca ou de sugestão automática.
Se parte do seu uso do HERE é sugestão automática em vez de geocodificação pura, vale a pena tratar isso como uma etapa de migração própria, já que endpoints no estilo de preenchimento automático têm seu próprio formato de resposta e um padrão de requisição que depende de entrada parcial, e merecem testes separados em vez de serem incluídos na virada da geocodificação. O uso da cota em cada requisição, incluindo o host de compatibilidade, fica visível por meio de cabeçalhos de resposta como X-Quota-Used e X-Credits-Remaining, documentados em /docs/rate-limits/.
Automações no-code construídas sobre uma etapa de geocodificação exigem uma abordagem de migração diferente da usada em código próprio. Veja como lidar com essa troca.
Trocar de fornecedor de dados de localização não é apenas uma decisão técnica. Veja o que revisar do lado do processamento de dados e da privacidade nessa mudança.
Desligar a chave de API de um provedor antigo cedo demais ou tarde demais traz riscos nos dois casos. Veja como aposentar credenciais corretamente quando uma migração estiver concluída.