Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Warum Kompatibilitäts-Hosts wichtiger sind als ein neues SDK
Jedes API-Unternehmen möchte, dass Sie sein SDK installieren. Ein SDK bindet. Sobald Ihre Codebasis eine Client-Bibliothek importiert, deren Methoden aufruft und von deren Objektstrukturen abhängt, bedeutet ein Anbieterwechsel, dass Sie den Code umschreiben müssen, der mit dem Anbieter kommuniziert, und nicht nur eine URL ändern. Diese Bindung ist oft das eigentliche Geschäftsmodell hinter einem kostenlosen und bequemen SDK, ob das nun jemand laut ausspricht oder nicht.
Wir haben einen anderen Weg gewählt. My Geocode hat 17 Kompatibilitäts-Hosts, von denen jeder die Anfrage- und Antwortstruktur eines anderen Anbieters nachbildet. Wenn Ihr Code bereits weiß, wie er den Endpunkt einer bekannten Geokodierungs-API aufruft und deren JSON parst, können Sie genau diesen Code auf unseren Kompatibilitäts-Host richten, und er funktioniert weiter. Kein SDK zu installieren, kein Parsing der Antworten umzuschreiben, kein proprietäres Objektmodell zu lernen.
Das klingt nach einer Kleinigkeit, bis Sie tatsächlich einmal versucht haben, ein Produktivsystem von einer API zu migrieren. Die Endpunkt-URL ist der einfache Teil. Der schwierige Teil ist jede Stelle in Ihrer Codebasis, die auf einen bestimmten Feldnamen zugreift, eine bestimmte Fehlerstruktur behandelt oder eine bestimmte Art der Paginierung voraussetzt. Diese Annahmen verteilen sich über Jahre in einer Codebasis, an Stellen, an deren Prüfung niemand mehr denkt. Ein Kompatibilitäts-Host macht es überflüssig, sie zu finden und zu korrigieren, weil sich die Struktur nicht ändert.
Ein SDK löst dagegen ein Problem, das Sie nur einmal haben, nämlich die erste Anbindung an eine API, und zwar um den Preis eines Problems, das Sie über die gesamte Lebensdauer des Produkts begleitet: die Bindung an die Designentscheidungen dieses SDK. Wenn das SDK eine inkompatible Änderung ausliefert, müssen Sie sie auffangen. Wenn es eine Sprachanbindung, auf die Sie angewiesen sind, nicht mehr pflegt, müssen Sie auch das auffangen. Ein einfacher HTTP-Kompatibilitäts-Host hat keine solche Angriffsfläche. Er ist nur eine URL, die die Antwortstruktur zurückgibt, die Sie bereits lesen können.
Wir sind nicht grundsätzlich gegen SDKs. Ein schlanker Wrapper, der Ihnen HTTP-Boilerplate erspart, ist eine Annehmlichkeit und keine Falle, solange der spätere Abschied von ihm nicht dasselbe Projekt ist wie ein Anbieterwechsel. Die Falle entsteht, wenn die Strukturen des SDK die einzigen sind, die Ihr Code versteht, sodass ein Wechsel Umschreiben statt Umkonfigurieren bedeutet.
17 Kompatibilitäts-Hosts zu bauen, war für uns mehr Arbeit, als ein einziges SDK zu bauen gewesen wäre. Jeder Host muss die Antwortstruktur eines anderen Anbieters Feld für Feld genau treffen, damit bestehende Integrationen keinen Unterschied bemerken. Wir haben diese Arbeit geleistet, weil sie die Wechselkosten von Ihrer Seite auf unsere verlagert. Sie können testen, ob unsere Daten, unsere Verfügbarkeit und unsere Preise für Sie passen, ohne erst Integrationskosten zu zahlen, nur um es herauszufinden. In der vollständigen Liste der Kompatibilitäts-Hosts oder in der Dokumentation sehen Sie, wie jeder einzelne dem Original entspricht.
Ein neues SDK verlangt von einem Entwickler, den technischen Entscheidungen eines Unternehmens für die gesamte Lebensdauer eines Projekts zu vertrauen. Ein Kompatibilitäts-Host verlangt viel weniger: eine Basis-URL ändern, vielleicht einen API-Schlüssel, und sehen, was passiert. Das ist ein fairerer Tausch, und genau deshalb haben wir Kompatibilitäts-Hosts gebaut, bevor wir irgendetwas anderes gebaut haben.