Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
Migration von HERE Geocoding and Search
HERE Geocoding and Search ist in Automobil- und Logistiksoftware weit verbreitet, also in Branchen, in denen ein Unternehmenskonto mit einem festen Ansprechpartner und einem Supportvertrag die übliche Arbeitsweise ist. Die Authentifizierung erfolgt meist über einen API-Schlüssel oder ein OAuth-Token, und Antworten kommen als items-Array zurück, in dem jeder Eintrag ein position-Objekt und einen strukturierten address-Block mit Feldern wie label, countryCode und houseNumber enthält.
Diese Struktur ist in Unternehmen, die darauf angewiesen sind, meist gut intern dokumentiert, weil HERE oft gezielt wegen seiner Qualität beim Adressparsing in einer bestimmten Region oder wegen seiner Routing-Integration an anderer Stelle im Stack gewählt wird. Eine Migration, die die Antwortform bricht, bricht diesen gesamten nachgelagerten Code auf einmal, und deshalb zählt hier die Kompatibilität mehr als der Aufwand für den Wechsel des Kontos selbst.
Der Kompatibilitätshost von My Geocode für HERE bildet das items-Array mit seinen verschachtelten Feldern position und address genau so nach, wie HERE sie zurückgibt, wobei nur die Texte zu Urheberrecht, Nutzungsbedingungen und Datenschutz ersetzt sind. Die Feldreferenz finden Sie unter /compatibility/here/. In den meisten Fällen müssen Sie im Anwendungscode nur den Hostnamen und den Schlüssel ändern, nichts in dem Code, der items[0].position oder items[0].address.label liest.
Unternehmensteams, die von HERE wegmigrieren, haben die Geokodierung oft in mehreren Diensten statt in einem angebunden, deshalb hilft es, zuerst jede Aufrufstelle zu erfassen: Batch-Jobs, Formulare zur Adressvalidierung, Lieferrouting und alle Admin-Werkzeuge greifen meist unabhängig voneinander auf dieselbe API zu. Sie Dienst für Dienst umzustellen, beginnend mit etwas mit wenig Verkehr, ist ein sinnvoller Weg, den neuen Host unter realen Bedingungen zu validieren, bevor die Aufrufe mit dem meisten Volumen wechseln.
Zur Authentifizierung: Ein von My Geocode ausgestellter Schlüssel kann als X-API-Key-Header, als Authorization: Bearer-Header, per HTTP Basic Auth oder als Query-Parameter gesendet werden. Wenn sich Ihre bestehende HERE-Client-Bibliothek bereits auf eine bestimmte Weise authentifiziert, reicht es meist, sie mit einem neuen Schlüssel auf den neuen Host zu richten, da die Bibliothek selbst nicht geändert werden muss.
Die Preisgestaltung erspart Ihnen eine Verhandlungsebene, die Unternehmensverträge oft mit sich bringen. Es gibt keine gestaffelte Kontostruktur: 2.500 Anfragen pro Tag sind ohne Schlüssel kostenlos, jeder Schlüssel fügt weitere 2.500 kostenlose Anfragen pro Tag hinzu, gezählt pro Netzwerk, und darüber hinaus gibt es Prepaid-Guthaben zu 0,0001 € pro Anfrage oder einen Unlimited-Schlüssel für 50 € pro Monat. Jeder Endpunkt, einschließlich dieses Kompatibilitätshosts, kostet gleich viel, sodass es keine separate Verhandlung über das Volumen für Geokodierung im Vergleich zu Suche oder Autosuggest gibt.
Wenn ein Teil Ihrer HERE-Nutzung Autosuggest statt reiner Geokodierung ist, sollten Sie das als eigenen Migrationsschritt behandeln, da Endpunkte im Stil der Autovervollständigung ihre eigene Antwortform und ein Anfragemuster haben, das von unvollständigen Eingaben abhängt. Das verdient separate Tests, statt in eine Umstellung der Geokodierung eingerechnet zu werden. Die Kontingentnutzung ist bei jeder Anfrage, auch auf dem Kompatibilitätshost, über Antwort-Header wie X-Quota-Used und X-Credits-Remaining sichtbar, dokumentiert unter /docs/rate-limits/.