Os provedores de geolocalização de IP usam, em sua maioria, categorias parecidas de dados de base (país, região, cidade, coordenadas e titularidade da rede), mas os empacotam em formatos visivelmente diferentes, e esses formatos determinam uma parte surpreendente do trabalho real de integração quando você avalia ou troca de provedor.
O ip-api.com prefere uma estrutura plana. Campos como country, regionName, city, lat, lon, isp e query ficam diretamente no nível superior da resposta, sem aninhamento, o que torna a leitura rápida e o mapeamento para uma linha plana de banco de dados ou uma única linha de log simples.
O ipinfo.io compacta dois valores que costumam andar juntos em strings únicas: um campo loc que guarda latitude e longitude juntas em uma string separada por vírgula, e um campo org que combina o número do sistema autônomo e o nome da organização em uma só string, algo como um número AS seguido do nome de uma empresa. Isso é eficiente para logs e exibição rápida, mas exige uma operação de divisão antes que qualquer um dos valores possa ser usado como um número de verdade ou comparado programaticamente.
O ipstack segue na direção oposta, com mais estrutura. Ele retorna campos de nível superior como type, continent_code, latitude e longitude como valores separados e agrupa os detalhes de rede e de ISP em um objeto connection aninhado, em vez de uma string plana, o que combina com aplicações que querem tratar esses detalhes como uma informação própria e distinta.
Nenhum desses três formatos é objetivamente melhor; eles refletem suposições diferentes sobre como quem chama vai usar os dados. Uma estrutura plana é mais rápida para escrever código de parsing improvisado. Uma estrutura compacta com strings combinadas é eficiente para pipelines de log que armazenam uma linha por requisição. Uma estrutura aninhada mantém os campos relacionados agrupados para aplicações que constroem um modelo de dados interno mais elaborado.
O My Geocode mantém hosts de compatibilidade para esses três formatos exatos: os campos planos do ip-api em /compatibility/ip-api/, as strings compactas loc e org do ipinfo em /compatibility/ipinfo/ e o objeto aninhado connection do ipstack em /compatibility/ipstack/. Isso significa que uma comparação como esta não precisa terminar com um único vencedor escolhido para todos; uma equipe pode usar o formato que o seu código atual já espera, ou até testar mais de um formato com os mesmos dados de consulta durante uma avaliação, já que os três hosts ficam na mesma plataforma, com as mesmas opções de autenticação e os mesmos preços.
Como as consultas de IP funcionam de ponta a ponta aqui, e não apenas no formato, essa comparação pode ser testada diretamente: aponte um pequeno script para os três hosts de compatibilidade com os mesmos endereços IP de teste e compare a estrutura real de saída que o seu próprio código de parsing receberia. A autenticação em qualquer um deles aceita um cabeçalho X-API-Key, Authorization: Bearer, autenticação HTTP Basic ou um parâmetro de consulta, e 2.500 requisições por dia são gratuitas, sem precisar de chave, em qualquer um dos três, o que torna uma comparação estrutural lado a lado um exercício de baixo custo antes de se comprometer com um formato em vez de outro.