Migrer une automatisation Zapier ou Make vers un nouvel hôte de géocodage
Les automatisations sans code construites autour d'une étape de géocodage demandent une autre approche de migration que le code sur mesure. Voici comment gérer ce changement.
ipstack, ip-api.com ou ipinfo.io : comparer la structure des données
Les fournisseurs de géolocalisation IP s'appuient pour la plupart sur des catégories de données sous-jacentes similaires (pays, région, ville, coordonnées et propriétaire du réseau), mais ils les présentent sous des structures nettement différentes, et ces structures déterminent une part étonnante du travail d'intégration réel lorsque vous les évaluez ou passez de l'un à l'autre.
ip-api.com privilégie une structure plate. Des champs comme country, regionName, city, lat, lon, isp et query se trouvent directement au premier niveau de la réponse, sans imbrication, ce qui la rend rapide à lire et simple à faire correspondre à une ligne de base de données plate ou à une seule ligne de journal.
ipinfo.io regroupe deux valeurs souvent associées dans des chaînes uniques : un champ loc qui contient la latitude et la longitude ensemble sous forme de chaîne séparée par une virgule, et un champ org qui combine le numéro de système autonome et le nom de l'organisation dans une seule chaîne, par exemple un numéro d'AS suivi d'un nom d'entreprise. C'est efficace pour la journalisation et l'affichage rapide, mais cela impose une opération de découpage avant que l'une ou l'autre valeur puisse être utilisée comme un véritable nombre ou comparée par programme.
ipstack prend la direction inverse avec davantage de structure. Il renvoie des champs de premier niveau comme type, continent_code, latitude et longitude sous forme de valeurs distinctes, et regroupe les informations sur le réseau et le FAI dans un objet imbriqué connection plutôt que dans une chaîne plate, ce qui convient aux applications qui veulent traiter ces informations comme une donnée à part entière.
Aucune de ces trois structures n'est objectivement meilleure ; elles reflètent des hypothèses différentes sur la façon dont l'appelant utilisera les données. Une structure plate permet d'écrire plus vite du code d'analyse ad hoc. Une structure compacte à chaînes combinées est efficace pour les pipelines de journalisation qui stockent une ligne par requête. Une structure imbriquée garde les champs liés regroupés pour les applications qui construisent un modèle de données interne plus élaboré.
My Geocode exploite des hôtes compatibles pour ces trois structures exactes : les champs plats d'ip-api sur /compatibility/ip-api/, les chaînes compactes loc et org d'ipinfo sur /compatibility/ipinfo/, et l'objet imbriqué connection d'ipstack sur /compatibility/ipstack/. Ainsi, une comparaison comme celle-ci n'a pas à désigner un gagnant unique imposé à tous : une équipe peut utiliser la structure que son code existant attend déjà, ou même tester plusieurs structures sur les mêmes données de recherche pendant une évaluation, puisque les trois hôtes reposent sur la même plateforme, avec les mêmes options d'authentification et les mêmes tarifs.
Comme les recherches d'IP fonctionnent ici entièrement de bout en bout, et pas seulement au niveau du format, cette comparaison peut être testée directement : dirigez un petit script vers les trois hôtes compatibles avec les mêmes adresses IP de test et comparez la structure de sortie réelle que recevrait votre propre code d'analyse. L'authentification sur chacun d'eux accepte un en-tête X-API-Key, Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête, et 2 500 requêtes par jour sont gratuites sans clé sur les trois, ce qui fait d'une comparaison structurelle côte à côte un exercice peu coûteux avant de vous engager sur une structure plutôt qu'une autre.