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 MapQuest Geocoding
MapQuest Geocoding existe depuis assez longtemps pour que de nombreuses intégrations construites dessus soient antérieures à une grande partie de la vague actuelle d'API cartographiques. Sa clé, générée via un compte développeur MapQuest, est envoyée comme paramètre de requête, et ses réponses renvoient un tableau results contenant un tableau imbriqué locations, chacun portant un objet latLng et une structure d'adresse détaillée avec des champs comme adminArea5 pour la ville et postalCode pour le code postal ou ZIP.
Les intégrations aussi anciennes portent parfois un type particulier de dette technique : le code qui appelle MapQuest a peut-être été écrit par quelqu'un qui ne fait plus partie de l'équipe, avec des commentaires faisant référence à des décisions dont personne ne se souvient. Ce n'est pas une raison pour éviter de migrer, mais c'est une raison de tester minutieusement plutôt que de supposer que le code existant est bien compris par la personne qui effectue la migration aujourd'hui.
L'hôte de compatibilité MapQuest de My Geocode reproduit la structure des tableaux results et locations ainsi que les champs latLng et d'adresse, en ne modifiant que les textes de copyright, de conditions et de confidentialité. Tous les détails se trouvent sur /compatibility/mapquest/. Dans la plupart des cas, mettre à jour l'hôte et la clé constitue l'intégralité du changement ; le schéma d'accès imbriqué results[0].locations[0].latLng devrait continuer à renvoyer des données de même forme.
Un ordre d'opérations raisonnable pour une intégration ancienne comme celle-ci :
- Repérez chaque endroit du code qui fait référence à l'hôte ou à la clé MapQuest, car le code ancien code parfois les deux en dur au lieu de les lire depuis la configuration
- Déplacez ces références dans la configuration si ce n'est pas déjà fait, quel que soit le fournisseur retenu
- Pointez un environnement de préproduction vers l'hôte de compatibilité et comparez un échantillon d'adresses réelles de production aux anciens résultats avant de toucher à quoi que ce soit en production
Côté nouveau fournisseur, l'authentification accepte un en-tête X-API-Key, un en-tête Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête : quelle que soit la manière dont l'ancienne clé MapQuest était envoyée, une option correspondante existe ici.
La tarification est forfaitaire et n'exige aucun choix de niveau de compte : 2 500 requêtes par jour gratuites sans clé, 2 500 de plus gratuites par clé et par jour, comptées par réseau, puis du crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois. Chaque endpoint, y compris cet hôte de compatibilité, coûte le même montant, ce qui supprime une variable que les anciens contrats comportaient parfois sous la forme de sauts de palier liés au volume.
Pour une intégration MapQuest qui a discrètement continué à fonctionner pendant des années sans beaucoup d'attention, l'objectif d'une telle migration est qu'elle reste aussi discrète ensuite : même forme de réponse, même code, un hôte et une clé différents en coulisses.