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.
Quitter une intégration d'altitude Google Maps Platform
La recherche d'altitude est généralement une dépendance discrète, appelée depuis la fonction de profil d'itinéraire d'une application de randonnée, un planificateur de vol de drone qui vérifie la marge de franchissement du relief ou un outil de relevé topographique, et elle est rarement la raison d'être d'un compte Google Maps Platform. Elle constitue donc une bonne candidate pour une migration indépendante du reste d'une intégration Google plus large, car le code appelant tient généralement dans une ou deux fonctions.
L'API Elevation de Google accepte une ou plusieurs paires de coordonnées et renvoie une valeur elevation en mètres ainsi qu'une valeur resolution décrivant la précision de l'échantillon de données sous-jacent. C'est une réponse compacte avec peu de choses à analyser, ce qui maintient la migration elle-même dans un périmètre assez réduit, même si la source de données sous-jacente change.
My Geocode propose l'altitude comme un endpoint pleinement fonctionnel avec une forme de requête et de réponse simple : envoyez une coordonnée, recevez l'altitude du sol en mètres. Comme il s'agit de l'une des recherches pour lesquelles de vraies réponses peuvent être décrites directement, et pas seulement la forme de la réponse, tester cette migration sur des points de référence connus (le sommet d'une montagne précise ou un lieu côtier au niveau de la mer) est un moyen raisonnable de gagner en confiance avant de basculer le trafic de production. Les détails se trouvent sur /docs/elevation-lookup/.
Quelques points à vérifier spécifiquement pour cette migration :
- Si votre code dépend du champ
resolutionde Google pour autre chose que l'affichage, car une valeur de résolution décrit la précision d'échantillonnage différemment selon les sources de données d'altitude, et toute logique en aval qui dépend d'une valeur de résolution précise mérite d'être revue - Si les recherches d'altitude se font par lots (de nombreuses coordonnées en un seul appel) ou individuellement, car la forme des requêtes par lots diffère d'un fournisseur à l'autre et mérite d'être testée avec les tailles de lot que votre application utilise réellement
- Si l'altitude est appelée directement depuis du code côté client, auquel cas c'est un bon moment pour déplacer l'appel côté serveur, quel que soit le fournisseur de destination
L'authentification utilise une clé envoyée via X-API-Key, Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête. Il y a 2 500 requêtes gratuites par jour sans aucune clé, et 2 500 de plus gratuites par clé et par jour, comptées par réseau, avec au-delà du crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois, au même prix que tous les autres endpoints de la plateforme.
Des extras optionnels au-delà de l'altitude elle-même, comme le détail des menaces liées à l'IP et des informations réseau utiles à d'autres parties d'une application, sont disponibles sur les hôtes de compatibilité via mg_extras=1, mais pour une migration purement liée à l'altitude comme celle-ci, l'endpoint autonome est généralement la solution la plus simple et la plus directe. Déplacer l'altitude seule, avant une migration plus importante du géocodage, est une façon peu risquée de commencer à réduire la dépendance à un compte unique sans vous engager tout de suite dans un projet plus conséquent.