My Geocode

Migration

Migrer depuis Bing Maps REST Services

· 3 min de lecture · My Geocode · #bing-maps#migration#géocodage#api-rest#compatibilité

Bing Maps REST Services a un format de réponse reconnaissable : un objet de premier niveau avec un tableau resourceSets, contenant chacun des resources, chaque ressource portant un objet point dont les coordonnées sont imbriquées dans un tableau coordinates plutôt que dans des champs latitude et longitude séparés. Les développeurs qui ont construit sur cette API, souvent dans des équipes .NET où Bing Maps s'imposait naturellement, connaissent cette structure par cœur, et tout réécrire autour d'une autre structure est exactement le genre de travail discret et fastidieux qui repousse une migration pendant des mois.

Une clé générée via le Bing Maps Dev Center est envoyée en paramètre de requête, un modèle commun à la plupart des API de cartographie grand public. Cette partie de l'intégration est généralement le moindre des soucis ; c'est l'analyse de la réponse qui concentre le vrai couplage.

My Geocode exploite un hôte compatible Bing Maps qui reproduit exactement cette structure resourceSets, de sorte que le code d'analyse qui lit resourceSets[0].resources[0].point.coordinates continue de fonctionner après le changement. Le seul contenu de la réponse qui diffère du format d'origine de Bing est le texte relatif aux droits d'auteur, aux conditions et à la confidentialité, qui est nécessairement le nôtre. Tous les détails se trouvent sur /compatibility/bing-maps/.

Quelques points à vérifier avant la bascule :

  • Vérifiez si votre code lit les champs de confiance ou de code de correspondance, car ils méritent une rapide comparaison côte à côte
  • Vérifiez quel mode d'authentification utilise votre bibliothèque cliente ; une clé peut être envoyée en X-API-Key, en Authorization: Bearer, en authentification HTTP Basic ou en paramètre de requête, donc le mode que votre bibliothèque utilise déjà devrait continuer de fonctionner
  • Décidez si vous voulez activer les champs supplémentaires facultatifs (altitude, menaces IP, informations réseau) via mg_extras=1, car ils s'ajoutent au format standard au lieu de le remplacer

L'aspect commercial est simple en comparaison. Il n'y a aucune étape de création de compte de facturation : 2 500 requêtes par jour sont gratuites sans aucune clé, et chaque clé dispose de ses propres 2 500 requêtes gratuites par jour, décomptées par réseau. Au-delà de ce quota, c'est du crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois, et l'hôte compatible coûte le même prix que tous les autres endpoints de la plateforme.

Pour les équipes qui utilisent le géocodage au sein d'une application .NET ou d'entreprise plus large, la migration a généralement une portée plus réduite qu'il n'y paraît de l'extérieur, car l'enveloppe resourceSets est normalement lue via une poignée de méthodes d'accès bien circonscrites plutôt que dispersée dans tout le code. Repérer d'abord ces points d'accès, puis les diriger vers le nouvel hôte dans un environnement de préproduction, est une bonne façon de valider le changement avant de toucher au trafic de production.

Si votre intégration appelle aussi un endpoint de fuseau horaire ou d'altitude de Bing en plus du géocodage, ceux-ci se traitent séparément, car les recherches de fuseau horaire et d'altitude de My Geocode fonctionnent indépendamment de l'hôte compatible de géocodage et méritent d'être branchées selon leurs propres règles plutôt que de passer de force par le même chemin de code. Tous les détails sur les quotas, y compris l'en-tête X-Quota-Limit et les en-têtes de réponse associés que porte chaque requête, sont documentés sur /docs/rate-limits/.

Plus d'articles sur la migration