Migração

Migrando do Google Maps Platform: o que muda e o que continua igual

A Google Maps Platform costuma ser a primeira API de geocodificação que uma equipe integra, principalmente porque é o nome mais conhecido do mercado. O modelo de autenticação dela já é familiar para a maioria dos desenvolvedores: uma chave de API vinculada a uma conta de faturamento dentro de um projeto do Google Cloud, enviada como parâmetro de consulta em cada requisição. As respostas de geocodificação vêm como um objeto JSON com um array results, um campo status, uma string formatted_address e um objeto aninhado geometry.location com a latitude e a longitude.

O que geralmente preocupa as equipes na hora de trocar é o código de parsing construído em torno desse formato exato. Componentes de endereço, limites de viewport, IDs de lugar, tudo isso é lido por funções espalhadas pelo código, e reescrever essas funções é o tipo de tarefa que ninguém quer agendar. Esse é justamente o problema que um host de compatibilidade foi criado para evitar.

O My Geocode mantém um host de compatibilidade com o Google Maps que reproduz campo a campo o formato de requisição e resposta de geocodificação do próprio Google. O único texto da resposta que é nosso é a linguagem de copyright, termos e privacidade; todo o resto, incluindo nomes de campos e aninhamento, corresponde ao que o seu código já espera. Na prática, migrar significa trocar um nome de host e uma chave, sem mexer em um parser. Os detalhes estão em /compatibility/google-maps/.

O que permanece igual:

  • A estrutura JSON que o seu código já interpreta
  • O estilo de enviar a chave como parâmetro de consulta, se é isso que o seu cliente usa
  • O padrão geral de requisição (entra um endereço, saem dados de localização estruturados)

O que muda:

  • O host para o qual você envia as requisições
  • A própria chave, emitida por nós em vez do Google
  • A exigência de conta de faturamento, substituída por um modelo mais simples de crédito ou assinatura

Como uma chave pode ser enviada como cabeçalho X-API-Key, cabeçalho Authorization: Bearer, autenticação HTTP Basic ou parâmetro de consulta, uma biblioteca cliente que já se autentica do seu próprio jeito tende a continuar funcionando sem modificações. Essa flexibilidade importa mais do que parece, já que boa parte da dor de uma migração, na prática, vem de bibliotecas que pressupõem uma forma específica de passar credenciais.

Quanto aos preços, o modelo é simples: 2.500 requisições por dia são gratuitas a partir de qualquer endereço, sem chave, e cada chave também recebe 2.500 requisições gratuitas por dia contadas por rede. Acima disso, é crédito pré-pago a € 0,0001 por requisição ou um pacote Unlimited a € 50 por mês, e todos os endpoints, incluindo todos os hosts de compatibilidade, custam o mesmo. Não há níveis separados para negociar conforme o produto que você chama.

Os campos extras opcionais (altitude do terreno, sinais de ameaça de IP e detalhes de rede) estão disponíveis em qualquer host de compatibilidade adicionando mg_extras=1 ou um cabeçalho X-MG-Extras, sem quebrar o formato do qual o resto do seu código depende. Isso dá a você um caminho para dados mais ricos no futuro, sem uma segunda migração.

Se a sua integração também usa geocodificação reversa, preenchimento automático ou consultas de código postal, a mesma troca de host e chave se aplica, embora valha a pena revisar o formato exato de requisição e resposta desses endpoints em relação ao seu código atual antes da virada, já que as convenções de formatação de endereços variam de país para país. Testar uma parte do tráfego de produção no novo host antes da troca completa é uma forma razoável de confirmar que o formato corresponde ao que você espera. Veja /docs/compatibility/ para a referência completa de campos de todos os hosts de compatibilidade.