Von fremden Diensten abhängen
Jeder angebundene externe Dienst ist ein Teil Ihres Produkts, den Sie nicht kontrollieren und nicht reparieren können. Das ist in Ordnung — solange Sie es bewusst entschieden haben.
Eine externe API anzubinden ist meist der schnellste Weg zu einer Fähigkeit — und verschiebt still einen Teil Ihrer Verlässlichkeit in fremde Hände. Die Arbeit besteht darin zu entscheiden, was passiert, wenn diese Hand abrutscht.
Entscheiden Sie vor dem Ausfall, was beim Ausfall geschieht
Jeder Dienst fällt irgendwann aus, zu einem Zeitpunkt, den Sie nicht gewählt haben. Die Frage, die man beantwortet, solange nichts kaputt ist: Scheitert Ihre Funktion, arbeitet sie eingeschränkt weiter, oder wartet sie?
Scheitern ist bei Optionalem akzeptabel — eine Karte, die nicht lädt, eine Anreicherung, die leer bleibt. Auf einem Zahlungs- oder Anmeldeweg ist es das nicht; dort brauchen Sie einen Ersatzweg oder einen ehrlichen Fehler, der sagt, was zu tun ist. Ein Ladekreis, der nie endet, ist das schlechteste Ergebnis: Er lehrt Menschen, dass Ihr Produkt kaputt ist, nicht das fremde.
Schlüssel sind Zugangsdaten, keine Konfiguration
Ein API-Schlüssel ist ein Passwort, das zufällig in einer Konfigurationsdatei steht — und wird wie eine Einstellung behandelt, weil er wie eine aussieht. Dann landet er im Repository, in einem Screenshot, in einem Nachrichtenverlauf.
Halten Sie Schlüssel vollständig aus dem Code, nutzen Sie je Umgebung einen eigenen, damit ein Test nie Livedaten berührt, und wechseln Sie sie, wenn jemand mit Zugriff geht. Geben Sie jedem Schlüssel außerdem den engsten Umfang, den der Dienst anbietet — fast jede API erlaubt das, und fast niemand nutzt es vor dem Vorfall, nach dem man es sich gewünscht hätte.
Rate Limits und die Wiederholungen, die sie verschlimmern
Das Erste, was die meisten Integrationen nach einem Fehlschlag tun, ist sofort erneut anzufragen. War der Fehlschlag ein Rate Limit, haben Sie es gerade verschärft, und ein voller Vormittag wird zum selbstverschuldeten Ausfall.
Wiederholen Sie mit wachsender Wartezeit, begrenzen Sie die Versuche und hören Sie danach auf, statt zu kreisen. Und wiederholen Sie nie blind einen nicht idempotenten Schreibvorgang — die klassische Variante dieses Fehlers ist eine doppelt belastete Kundin, weil der erste Aufruf erfolgreich war und nur die Antwort verloren ging.
Er wird sich unter Ihnen ändern
Dienste ändern Antwortformate, stellen Endpunkte ein und passen Limits an — angekündigt meist dort, wo Sie nicht gelesen haben. Die Integration, die ein Jahr lief, ist nicht stabil; sie ist seit der letzten Änderung ungetestet.
Pinnen Sie eine Version, wenn der Dienst eine anbietet, abonnieren Sie die Änderungsmeldungen mit einer echten Person statt eines ungelesenen Sammelpostfachs, und halten Sie einen kleinen täglichen Aufruf, der meldet, wenn die Antwort nicht mehr aussieht wie früher. Der kostet eine Stunde und findet den Bruch vor der Kundschaft.
Häufig gestellte Fragen
Was ist vor einer Anbindung zu entscheiden?
Was bei Ausfall geschieht: scheitern, eingeschränkt weiterlaufen oder warten. Bei Optionalem ist Scheitern in Ordnung; auf Zahlungs- oder Anmeldewegen braucht es einen Ersatzweg oder einen ehrlichen Fehler.
Wie geht man mit API-Schlüsseln um?
Als Zugangsdaten, nicht als Konfiguration. Aus dem Repository heraushalten, je Umgebung ein eigener Schlüssel, wechseln, wenn jemand mit Zugriff geht, und den Umfang jedes Schlüssels eng halten.
Wie sollen Wiederholungen funktionieren?
Mit wachsender Wartezeit und begrenzter Versuchszahl, danach aufhören. Sofortiges Wiederholen macht aus einem Rate Limit einen selbstverschuldeten Ausfall, und blindes Wiederholen eines Schreibvorgangs belastet Kundschaft doppelt.
