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 de fuseau horaire Bing Maps
La fonctionnalité de fuseau horaire de Bing est généralement accessible soit via son API Locations avec un indicateur de fuseau horaire, soit via un appel de fuseau horaire dédié, selon la façon dont l'intégration a été construite à l'origine. Dans les deux cas, elle réside généralement dans le même compte Bing Maps Dev Center que le géocodage, ce qui signifie qu'une bascule complète du compte toucherait normalement les deux à la fois, même lorsque seule la partie fuseau horaire est réellement concernée.
Les données de fuseau horaire forment une réponse petite et bien délimitée : un identifiant, un décalage UTC et généralement une indication sur l'application de l'heure d'été pour la coordonnée et la date données. Cette compacité est un véritable avantage pour planifier une migration, car il y a comparativement peu de structure de réponse à vérifier sur des cas de test réels avant de considérer la migration comme terminée.
La recherche de fuseau horaire de My Geocode fonctionne comme un endpoint indépendant et pleinement fonctionnel, documenté sur /docs/timezone-lookup/, entièrement séparé des hôtes de compatibilité de géocodage. Elle renvoie directement les informations de fuseau horaire pour une coordonnée, ce qui signifie que cette migration ne nécessite pas de décider d'abord quoi que ce soit concernant le reste d'une intégration Bing Maps. Les équipes peuvent déplacer les appels de fuseau horaire dès maintenant et prendre plus de temps pour évaluer s'il faut aussi migrer le géocodage.
Étapes à suivre pour cette migration en particulier :
- Identifiez chaque fonction qui appelle actuellement la fonctionnalité de fuseau horaire de Bing, en gardant à l'esprit qu'elle peut être intégrée dans un appel plus large à l'API Locations plutôt que dans un endpoint distinct du code existant
- Extrayez cette logique dans sa propre fonction au nom explicite si elle n'est pas déjà séparée, ce qui fait du changement de fournisseur proprement dit une modification unique et localisée
- Testez le nouvel endpoint sur des coordonnées au comportement de fuseau horaire inhabituel connu (régions avec des décalages qui ne sont pas des heures entières, lieux sans heure d'été) avant de considérer la migration comme vérifiée
L'authentification utilise une clé, envoyée via X-API-Key, Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête, selon ce qui correspond le mieux à la façon dont le reste de votre application envoie déjà ses identifiants à d'autres services.
La tarification est uniforme : 2 500 requêtes gratuites par jour sans clé requise, 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, sans tarif distinct pour la recherche de fuseau horaire par rapport à tout autre endpoint. Étant donné le petit nombre d'appels de fuseau horaire que la plupart des applications effectuent réellement par rapport au volume de géocodage, il est courant que cette partie reste largement dans le quota quotidien gratuit, même après une migration complète : vérifiez-le avec vos propres chiffres avant de supposer qu'elle nécessite un forfait payant.