Migration

Migration von der Google Maps Platform: was sich ändert, was bleibt

Google Maps Platform ist oft die erste Geokodierungs-API, die ein Team überhaupt anbindet, vor allem weil es der größte Name im Raum ist. Das Authentifizierungsmodell ist den meisten Entwicklern inzwischen vertraut: ein API-Schlüssel, der an ein Abrechnungskonto in einem Google-Cloud-Projekt gebunden ist und bei jeder Anfrage als Query-Parameter gesendet wird. Die Geokodierungsantworten kommen als JSON-Objekt mit einem results-Array, einem status-Feld, einer formatted_address-Zeichenkette und einem verschachtelten geometry.location-Objekt mit Breiten- und Längengrad zurück.

Was Teams beim Wechsel meist Sorgen macht, ist der Parsing-Code, der um genau diese Form herum gebaut ist. Adresskomponenten, Viewport-Grenzen, Place-IDs: All das wird von Funktionen gelesen, die über eine Codebasis verstreut sind, und diese Funktionen umzuschreiben ist die Art von Aufgabe, die niemand einplanen möchte. Genau dieses Problem soll ein Kompatibilitätshost vermeiden.

My Geocode betreibt einen Kompatibilitätshost für Google Maps, der das Anfrage- und Antwortformat der Google-Geokodierung Feld für Feld nachbildet. Der einzige Text in der Antwort, der von uns stammt, sind die Angaben zu Urheberrecht, Nutzungsbedingungen und Datenschutz; alles andere, einschließlich Feldnamen und Verschachtelung, entspricht dem, was Ihr Code bereits erwartet. In der Praxis bedeutet die Migration, einen Hostnamen und einen Schlüssel zu ändern, nicht einen Parser anzufassen. Details finden Sie unter /compatibility/google-maps/.

Was gleich bleibt:

  • Die JSON-Struktur, die Ihr Code bereits parst
  • Die Übergabe des Schlüssels als Query-Parameter, falls Ihr Client das so macht
  • Das allgemeine Anfragemuster (Adresse hinein, strukturierte Standortdaten heraus)

Was sich ändert:

  • Der Host, an den Sie Anfragen senden
  • Der Schlüssel selbst, ausgestellt von uns statt von Google
  • Die Pflicht zum Abrechnungskonto, ersetzt durch ein einfacheres Guthaben- oder Abonnementmodell

Da ein Schlüssel als X-API-Key-Header, als Authorization: Bearer-Header, per HTTP Basic Auth oder als Query-Parameter gesendet werden kann, funktioniert eine Client-Bibliothek, die sich bereits auf ihre eigene Weise authentifiziert, in der Regel ohne Änderung weiter. Diese Flexibilität ist wichtiger, als es klingt, denn viel Migrationsaufwand entsteht in der Praxis durch Bibliotheken, die von einer ganz bestimmten Art der Übergabe von Zugangsdaten ausgehen.

Das Preismodell ist einfach: 2.500 Anfragen pro Tag sind von jeder Adresse aus kostenlos, ohne dass ein Schlüssel nötig ist, und jeder Schlüssel erhält zusätzlich 2.500 kostenlose Anfragen pro Tag, gezählt pro Netzwerk. Darüber hinaus gibt es Prepaid-Guthaben zu 0,0001 € pro Anfrage oder ein Unlimited-Paket für 50 € pro Monat, und jeder Endpunkt, einschließlich jedes Kompatibilitätshosts, kostet gleich viel. Es gibt keine separaten Stufen, die Sie je nach aufgerufenem Produkt verhandeln müssten.

Optionale Zusatzfelder (Geländehöhe, IP-Bedrohungssignale und Netzwerkdetails) sind auf jedem Kompatibilitätshost verfügbar, wenn Sie mg_extras=1 oder einen X-MG-Extras-Header hinzufügen, ohne die Form zu verändern, von der der Rest Ihres Codes abhängt. So haben Sie später einen Weg zu reichhaltigeren Daten, ohne eine zweite Migration.

Wenn Ihre Integration auch Reverse-Geokodierung, Autovervollständigung oder Postleitzahlabfragen nutzt, gilt derselbe Austausch von Host und Schlüssel. Die genaue Anfrage- und Antwortform dieser Endpunkte sollten Sie vor der Umstellung aber mit Ihrem aktuellen Code abgleichen, da Konventionen zur Adressformatierung von Land zu Land variieren. Einen Teil des Produktionsverkehrs vor dem vollständigen Wechsel über den neuen Host zu testen, ist ein vernünftiger Weg, um zu bestätigen, dass die Form Ihren Erwartungen entspricht. Die vollständige Feldreferenz aller Kompatibilitätshosts finden Sie unter /docs/compatibility/.