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 eine Migration einen Nachmittag dauern sollte, nicht ein Quartal
Ein Migrationsprojekt, das für den Wechsel eines Anbieters von Standortdaten mit einem Quartal Entwicklungszeit veranschlagt wird, besteht meist nicht aus einem Quartal wirklich notwendiger Arbeit. Es ist ein Quartal Arbeit, das durch Designentscheidungen von vor Jahren entstanden ist: ein proprietäres Antwortformat, das Feld für Feld aufgelöst werden muss, ein SDK, dessen Methodenaufrufe an undokumentierten Stellen über die Codebasis verstreut sind, eine Fehlerbehandlung, die um die spezifischen Statuscodes eines einzigen Anbieters herum gebaut ist. Nichts von dieser Komplexität gehört von Natur aus zur Idee, eine Adresse oder eine IP abzufragen. All das ist geerbt aus Entscheidungen, die die ursprüngliche Integration bequem gemacht haben, um den Preis, eine künftige Migration teuer zu machen.
Wir haben 17 Kompatibilitäts-Hosts gebaut, um dieses Quartal für alle überflüssig zu machen, deren bestehende Integration bereits eine dieser Anbieterstrukturen spricht. Wenn Ihr Code den Endpunkt einer bekannten Geokodierungs- oder IP-API aufruft und deren spezifisches Antwortformat parst, sollte es genügen, eine Basis-URL und einen API-Schlüssel zu ändern, um denselben Code auf unseren passenden Kompatibilitäts-Host zu richten, statt die Parsing-Logik umzuschreiben, die seit Jahren einwandfrei funktioniert. Die Authentifizierung akzeptiert einen Schlüssel als Header, als Bearer-Token, per HTTP-Basic-Authentifizierung oder als Query-Parameter, sodass das Muster, das Ihr bestehender Code bereits verwendet, sehr wahrscheinlich schon unterstützt wird.
Eine Migration in der Größenordnung eines Nachmittags ist keine Behauptung, die wir leichtfertig aufstellen, denn wir wissen genau, wie viel Aufwand es auf unserer Seite gekostet hat, sie wahr zu machen: die Antwortstruktur eines anderen Anbieters Feld für Feld nachzubilden, sie mit echten Anfragen zu testen und diese Struktur stabil zu halten, damit der bestehende Code eines Kunden keinen Grund hat, einen Unterschied zu bemerken, außer wohin die Anfrage geht. Diese Arbeit wird bewusst vorab von uns erledigt, damit sie nicht noch einmal nachgelagert in der Codebasis jedes Kunden anfallen muss, der testen möchte, ob sich ein Wechsel lohnt.
Der allgemeinere Punkt reicht über unsere eigenen Kompatibilitäts-Hosts hinaus: Eine Migration, die ein Quartal dauert, sagt etwas über die vorherige Integration aus und ist keine natürliche Eigenschaft eines Anbieterwechsels im Allgemeinen. Wenn der Abschied von einem Anbieter ein mehrmonatiges Projekt erfordert, hat irgendjemand irgendwo von dieser Reibung profitiert, ob sie nun absichtlich geschaffen wurde oder nicht. Ein Anbieter, der wirklich von seinen Daten, seinen Preisen und seiner Zuverlässigkeit überzeugt ist, hat keinen Grund, einen Wechsel weg von ihm zu erschweren, denn das ganze Versprechen sollte sein, dass ein Kunde, der ihn ausprobiert, nicht mehr gehen will, und nicht, dass das Gehen zu teuer ist, um es zu versuchen.
Wir konkurrieren lieber darüber, ob es sich lohnt, beim Produkt zu bleiben, ehrlich bewertet, an demselben Nachmittag, an dem ein Kunde genauso leicht wieder wechseln könnte. Diesen Nachmittag möglich zu machen, hat uns echten technischen Aufwand gekostet. Wir finden, dass dieser Aufwand betrieben werden sollte, und dass jeder Anbieter, der ihn nicht betreiben will, Ihnen stillschweigend etwas darüber verrät, wie überzeugt er tatsächlich von dem ist, was er verkauft.