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.
Migrer depuis LocationIQ
LocationIQ se positionne autour des données géographiques ouvertes et d'un modèle d'authentification simple par clé, envoyée comme paramètre de requête, avec des réponses JSON contenant lat, lon, display_name et un objet address découpé en champs familiers à quiconque a déjà utilisé directement des données dérivées d'OpenStreetMap. Cette familiarité n'est pas un hasard : les fournisseurs qui s'appuient sur des sources de données ouvertes ont tendance à converger vers des noms de champs similaires, ce qu'il est utile de savoir si vous en comparez plusieurs à la fois.
Les équipes qui ont choisi LocationIQ l'ont souvent fait pour l'association d'un point d'entrée généreux et d'une intégration simple, sans devoir d'abord négocier un contrat entreprise. Une migration devrait idéalement préserver cette expérience plutôt que de l'échanger contre un processus d'intégration plus lourd.
L'hôte de compatibilité LocationIQ de My Geocode reproduit exactement les champs lat, lon, display_name et les composants d'adresse, seules les mentions de copyright, de conditions et de confidentialité différant de l'original. Les détails de référence se trouvent sur /compatibility/locationiq/. Le code applicatif qui lit response.display_name ou parcourt les champs de response.address ne devrait pas avoir à changer, hormis le nom d'hôte et la clé.
Une courte liste de contrôle pour cette migration en particulier :
- Vérifiez quelle méthode d'authentification votre bibliothèque cliente utilise aujourd'hui (LocationIQ accepte généralement un paramètre de requête) et comparez-la aux quatre styles pris en charge ici : l'en-tête
X-API-Key,Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête - Vérifiez si votre intégration appelle aussi un endpoint de géocodage inverse, car la forme de la requête y diffère du géocodage direct et mérite d'être testée séparément
- Passez en revue tout code de gestion de la limite de débit que vous avez écrit spécifiquement autour des en-têtes de réponse de LocationIQ, car les noms d'en-têtes diffèrent d'un fournisseur à l'autre et votre logique de nouvelle tentative peut y faire référence par leur nom
Côté tarifs, la comparaison est assez directe : aucune clé requise pour 2 500 requêtes par jour, et 2 500 de plus gratuites par clé et par jour, comptées par réseau, que ce soit en IPv4 (par /24) ou en IPv6 (par /48). Au-delà du quota gratuit, c'est du crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois, et chaque endpoint coûte le même prix, sans palier distinct pour le volume de géocodage par rapport aux autres recherches.
Si votre utilisation de LocationIQ est passée naturellement d'un projet secondaire à quelque chose dont des gens dépendent, un hôte de compatibilité est précisément conçu pour rendre ce type de migration ennuyeuse, au meilleur sens du terme : changer un nom d'hôte, changer une clé, et continuer à livrer. Le code d'analyse qui a demandé du temps pour être correct la première fois n'a pas besoin d'être repris simplement parce que le fournisseur derrière a changé. Une visibilité complète sur le quota, y compris l'utilisation par réseau, est fournie par les en-têtes de réponse standard documentés sur /docs/rate-limits/.