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.
Die stillen Kosten der Anbieterbindung
Niemand registriert sich bei einer API mit dem Plan, an sie gebunden zu werden. Anbieterbindung kommt nicht als Vertragsklausel daher, die Sie wegverhandeln können. Sie sammelt sich an, eine Bequemlichkeit nach der anderen, bis die Kosten eines Wechsels still und leise größer geworden sind als die Kosten des Problems, das Sie überhaupt erst über einen Wechsel nachdenken ließ.
Es fängt klein an. Sie installieren das SDK des Anbieters, weil es ein paar Stunden spart, in denen Sie HTTP-Aufrufe von Hand schreiben müssten. Sie speichern die Struktur des Antwortobjekts direkt in Ihrer Datenbank, statt sie auf Ihr eigenes Schema abzubilden, weil diese Abbildung damals wie unnötige Arbeit wirkte. Sie bauen die Fehlerbehandlung um die spezifischen Statuscodes des Anbieters herum statt um ein allgemeines Muster. Jede dieser Entscheidungen ist für sich genommen sinnvoll, im Moment, unter normalem Lieferdruck. Keine davon wird mit Blick auf Anbieterbindung getroffen. Alle tragen dazu bei.
Jahre später erhöht der Anbieter die Preise, hat in einer geschäftigen Phase einen Ausfall oder ist einfach nicht mehr die beste Option für eine Funktion, die Sie jetzt brauchen. Ein Wechsel sollte eine Sache sein, bei der Sie einen neuen Anbieter wählen und einen Konfigurationswert ändern. Stattdessen ist er ein Projekt: Parsing-Logik neu schreiben, die über die ganze Codebasis verstreut ist, Fehlerbehandlung neu aufbauen, alle internen Werkzeuge umstellen, die um die alte Struktur herum entstanden sind. Die Wechselkosten standen nie auf einer Rechnung. Sie wurden im Voraus bezahlt, in kleinen Integrationsentscheidungen, die damals niemand als riskant markiert hat.
Wir haben die Kompatibilitäts-Hosts genau gegen dieses Muster gebaut. Wenn Ihre Integration bereits die Anfrage- und Antwortstruktur eines anderen Anbieters spricht, müssen Sie nicht im Voraus für Portabilität geplant haben, um sie auf einen unserer 17 Kompatibilitäts-Hosts umzustellen. Sie erhalten die Möglichkeit zu wechseln, ohne die Voraussicht gehabt zu haben, für einen Wechsel zu bauen. Das ist ein bedeutender Unterschied zu den meisten Ratschlägen gegen Anbieterbindung, die meist lauten: „Bauen Sie vom ersten Tag an gegen eine Abstraktionsschicht.“ Das ist ein guter Rat, den unter Termindruck kaum jemand tatsächlich befolgt.
Die Authentifizierung ist ein kleineres Beispiel für dasselbe Prinzip. Manche Anbieter drängen Sie zu einer bestimmten Authentifizierungsmethode und binden Ihre Integration damit an ein bestimmtes Client-Muster. Wir akzeptieren einen Schlüssel als X-API-Key-Header, als Authorization-Bearer-Header, über HTTP Basic Auth oder als Query-Parameter, auf jedem Host und ohne Aufpreis für irgendeine dieser Methoden. Welches Muster Ihr bestehender Code auch für andere APIs verwendet, unseres passt wahrscheinlich dazu, sodass Sie Ihre Authentifizierungsschicht nicht umschreiben müssen, nur um uns auszuprobieren.
Der ehrliche Grund, warum sich Anbieterbindung in dieser Branche hält, ist, dass sie kommerziell funktioniert. Ein Kunde, der allein wegen des Preises wechseln würde, bleibt oft, weil ein Wechsel eine Neuentwicklung bedeutet. Wir halten das für einen schlechten Handel, um ein Geschäft darauf aufzubauen, denn so gewinnt man die Kunden, die bereits unzufrieden sind, statt derjenigen, die wirklich zufrieden sind. Wenn ein Wechsel günstig bleibt, bleiben die Kunden, weil sich das Produkt für sie noch lohnt, und nicht, weil der Ausgang irgendwann im zweiten Jahr still und leise zugemauert wurde.