Migration

Migration von Bing Maps REST Services

Bing Maps REST Services hat eine wiedererkennbare Antwortform: ein Objekt der obersten Ebene mit einem resourceSets-Array, das jeweils resources enthält, wobei jede Ressource ein point-Objekt trägt, dessen Koordinaten in einem coordinates-Array verschachtelt sind statt in separaten Feldern für Breiten- und Längengrad. Entwickler, die darauf aufgebaut haben, oft in .NET-Umgebungen, in denen Bing Maps die naheliegende Wahl war, kennen diese Struktur auswendig, und das Umschreiben auf eine andere ist genau die Art von stiller, mühsamer Arbeit, die eine Migration monatelang aus dem Kalender hält.

Ein über das Bing Maps Dev Center erzeugter Schlüssel wird als Query-Parameter gesendet, ein Muster, das die meisten Karten-APIs für Endverbraucher teilen. Dieser Teil der Integration ist meist die geringste Sorge; beim Parsen der Antwort liegt die eigentliche Kopplung.

My Geocode betreibt einen Kompatibilitätshost für Bing Maps, der genau diese resourceSets-Struktur nachbildet, sodass der Parsing-Code, der resourceSets[0].resources[0].point.coordinates liest, nach dem Wechsel weiter funktioniert. Der einzige Inhalt der Antwort, der nicht der ursprünglichen Form von Bing entspricht, sind die Texte zu Urheberrecht, Nutzungsbedingungen und Datenschutz, die notwendigerweise von uns stammen. Alle Details finden Sie unter /compatibility/bing-maps/.

Einige Punkte, die Sie vor der Umstellung prüfen sollten:

  • Klären Sie, ob Ihr Code Felder für Konfidenz oder Match-Codes liest, da sich hier ein kurzer direkter Vergleich lohnt
  • Klären Sie, welchen Authentifizierungsstil Ihre Client-Bibliothek verwendet; ein Schlüssel kann als X-API-Key, Authorization: Bearer, HTTP Basic Auth oder Query-Parameter gesendet werden, sodass die Variante, die Ihre Bibliothek bereits nutzt, weiter funktionieren sollte
  • Entscheiden Sie, ob Sie die optionalen Zusatzfelder (Höhe, IP-Bedrohung, Netzwerkdetails) über mg_extras=1 aktivieren möchten, da sie neben der Standardform stehen, statt sie zu ersetzen

Die kaufmännische Seite ist im Vergleich dazu einfach. Es gibt keinen Schritt zur Einrichtung eines Abrechnungskontos: 2.500 Anfragen pro Tag sind ganz ohne Schlüssel kostenlos, und jeder Schlüssel erhält seine eigenen 2.500 kostenlosen Anfragen pro Tag, gezählt pro Netzwerk. Über dieses Kontingent hinaus gibt es Prepaid-Guthaben zu 0,0001 € pro Anfrage oder einen Unlimited-Schlüssel für 50 € pro Monat, und der Kompatibilitätshost kostet genauso viel wie jeder andere Endpunkt der Plattform.

Für Teams, die Geokodierung als Teil einer größeren .NET- oder Unternehmensanwendung betreiben, ist die Migration meist kleiner, als sie von außen aussieht, weil der resourceSets-Wrapper normalerweise über eine Handvoll gut abgegrenzter Zugriffsmethoden gelesen wird, statt verstreut im gesamten Code. Diese Zugriffspunkte zuerst zu finden und sie dann in einer Staging-Umgebung auf den neuen Host zu richten, ist ein vernünftiger Weg, den Wechsel zu validieren, bevor Sie Produktionsverkehr anfassen.

Wenn Ihre Integration neben der Geokodierung auch einen Bing-Endpunkt für Zeitzonen oder Höhe aufruft, wird das separat behandelt, da die eigenen Zeitzonen- und Höhenabfragen von My Geocode unabhängig vom Kompatibilitätshost für die Geokodierung funktionieren und sich lohnen, eigenständig angebunden zu werden, statt sie durch denselben Codepfad zu zwingen. Alle Details zum Kontingent, einschließlich des X-Quota-Limit-Headers und der verwandten Antwort-Header, die jede Anfrage mitliefert, sind unter /docs/rate-limits/ dokumentiert.