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.
Mettre à jour les bibliothèques clientes et les SDK pendant une migration
De nombreuses intégrations de géocodage et de données de localisation ne communiquent pas du tout directement avec une API HTTP ; elles passent par une bibliothèque cliente officielle ou un SDK qui encapsule les requêtes, gère l'authentification et renvoie les résultats sous forme d'objets typés dans le langage de l'application. Cette couche supplémentaire est pratique au quotidien, mais elle complique réellement une migration, car la bibliothèque elle-même, et pas seulement l'API qui se trouve derrière, doit faire partie du plan.
Une migration impliquant une bibliothèque cliente se déroule généralement de trois manières, et il vaut la peine de déterminer laquelle s'applique avant de commencer :
La bibliothèque accepte une URL de base personnalisée. Certaines bibliothèques clientes officielles sont écrites avec assez de souplesse pour accepter une autre URL de base pour les requêtes tout en conservant le reste de leur interface, auquel cas diriger la bibliothèque existante vers un hôte de compatibilité, si la structure de réponse correspond à ce que la bibliothèque s'attend à analyser, peut fonctionner sans pratiquement aucune modification du code de l'application. C'est le meilleur cas, et il vaut la peine de le vérifier en premier.
La bibliothèque est étroitement liée à un seul hôte. De nombreuses bibliothèques clientes codent en dur leur hôte cible ou font des hypothèses propres au flux d'authentification de leur fournisseur, qui ne peuvent pas être facilement redirigées. Dans ce cas, la voie pragmatique consiste généralement à contourner entièrement la bibliothèque pour les appels migrés et à envoyer les requêtes directement à l'API du nouveau fournisseur, en remplaçant l'encapsulation typée de la bibliothèque par votre propre fonction de requête légère.
Aucune bibliothèque n'est impliquée. Si votre intégration effectue déjà des requêtes HTTP brutes sans bibliothèque officielle entre les deux, toute cette question ne s'applique pas, et la migration consiste plus directement à changer l'hôte, la clé et l'analyse des réponses qui doit être ajustée.
Comme l'authentification de My Geocode 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, une bibliothèque cliente qui s'authentifie déjà de l'une de ces manières courantes a de bonnes chances de fonctionner avec un hôte de compatibilité moyennant un simple changement d'URL de base et une nouvelle clé, même sans bibliothèque officielle propre à cette plateforme. Il vaut la peine de le tester directement dans un environnement de préproduction avant de supposer que cela fonctionnera sans modification ou que cela ne fonctionnera pas du tout ; le résultat réel dépend entièrement de la souplesse avec laquelle la bibliothèque en question a été écrite.
Quelle que soit la voie retenue, il vaut la peine de documenter explicitement la décision dans vos notes de migration, car une dépendance à une bibliothèque discrètement contournée pendant une migration sans être documentée a tendance à dérouter la personne qui maintient le code un an plus tard, lorsqu'elle met à jour l'ancienne bibliothèque en pensant qu'elle se trouve toujours sur le chemin des requêtes. Un court commentaire expliquant que les requêtes contournent désormais la bibliothèque cliente officielle, et pourquoi, évite une réelle confusion par la suite.