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.
Ein Plädoyer für langweilige, stabile API-Versionierung
Wenn ein Anbieter eine neue Hauptversion seiner API ankündigt, kündigt er damit jedem Kunden mit bestehender Integration in der Regel ein Projekt an, um das dieser nicht gebeten hat. Selbst eine gut kommunizierte inkompatible Änderung bedeutet, dass jemand Zeit einplanen muss, um einen Migrationsleitfaden zu lesen, die Verarbeitung von Anfragen oder Antworten anzupassen, alles zu testen und auszurollen, und zwar nach einem Zeitplan, den die Roadmap des Anbieters vorgibt und nicht irgendetwas im eigenen Produkt des Kunden.
Wir finden, API-Stabilität verdient es, als eigenständiges Entwurfsziel behandelt zu werden, nicht als Mangel an Tempo. Eine einmal veröffentlichte Antwortstruktur sollte weiterhin das bedeuten, was sie bedeutete, als ein Entwickler zum ersten Mal darauf aufgebaut hat. Neue Felder können als optionale Ergänzungen hinzukommen, so wie Höhe, IP-Bedrohung und Netzwerkdetails als optionale Extras auf Standardantworten aufsetzen, statt diese zwangsweise umzubauen. Was nicht still und leise passieren sollte: dass ein bestehendes Feld seine Bedeutung ändert, ein Statuscode umfunktioniert oder eine Struktur unter derselben Versionsnummer umgebaut wird.
Ein Grund, warum inkompatible Änderungen in dieser Branche so häufig vorkommen, ist, dass sie für den Anbieter billig und für den Kunden teuer sind, und die beiden Seiten verhandeln selten direkt über dieses Ungleichgewicht. Ein saubereres internes Modell auszuliefern, ist ein legitimer technischer Erfolg für das Team eines Anbieters. Zur Last wird es in dem Moment, in dem es jede nachgelagerte Integration zwingt, sich anzupassen, nach einem Zeitplan, den der Anbieter bestimmt und der Kunde nicht.
Das heißt nicht, dass sich eine API nie ändern sollte. Es heißt, dass Änderungen wo immer möglich additiv sein sollten, und wo eine echte inkompatible Änderung unvermeidlich ist, sollte sie so selten sein, dass ein Kunde darauf vertrauen kann, dass die Struktur, auf der er aufgebaut hat, auch Monate oder Jahre später noch funktioniert, und nicht etwas ist, wogegen er sich durch ständiges Beobachten eines Änderungsprotokolls wappnen muss. Stabilität ist nicht dasselbe wie Stillstand. Sie ist das Versprechen, dass die Integrationsarbeit von heute kein Ablaufdatum hat, von dem Ihnen niemand erzählt hat.
Über das Wohlwollen der Kunden hinaus haben wir auch einen eigennützigen Grund für diese Haltung. Jeder Kompatibilitäts-Host, den wir betreiben, hängt davon ab, die Struktur eines anderen Anbieters über lange Zeit treu nachzubilden, und das funktioniert nur, wenn einmal nachgebildete Strukturen es wert sind, sich als stabile Ziele auf sie zu verlassen. Ein Unternehmen, das seine eigene API-Oberfläche als Wegwerfware behandelt, die bei Gelegenheit neu entworfen wird, ist ein Unternehmen, dessen Kompatibilitätsgarantien auch keine echten Garantien sind. Stabilität muss eine Gewohnheit sein, die überall gilt, sonst gilt sie eigentlich nirgends.
Langweilig ist hier keine Kritik. Eine API-Version, die Jahre später noch genau so funktioniert wie bei Ihrer ersten Integration, ist kein Beleg dafür, dass sich nichts verbessert hat. Sie ist ein Beleg dafür, dass Verbesserungen auf eine Weise stattfanden, die Sie nicht bemerken mussten, und genau darum geht es bei guter Versionierungsdisziplin.