Zum Inhalt springen

Eine API-Version wechseln, ohne den Datenfluss zu übersehen

Beim API-Wechsel müssen Aufrufer, Datenbedeutung und Rückmeldungen zusammenpassen. Ein konkreter Testfall macht die Umstellung prüfbar.

Tobias Krüger2 Min. Lesezeit
Metalladapter mit Buchse neben zwei Steckmodulen mit den Kennzeichnungen v1 und v2 und gleichem blauen Datensymbol.

Planen Sie den Wechsel einer Programmierschnittstelle (API) entlang der betroffenen Datenflüsse. Der neue Endpunkt ist nur ein Teil der Umstellung: Auch Felder, Berechtigungen und die Auswertung von Antworten müssen zum aufrufenden System passen.

Die betroffenen Aufrufer erfassen

Im fiktiven Unternehmen senden Kundenportal und Nachtimport Aufträge an dieselbe API. Nur das Portal umzustellen würde den zweiten Aufrufer zurücklassen. Halten Sie für jeden Aufrufer fest, welche Funktionen er nutzt und wer seine Umstellung durchführen kann. Nutzen Sie die Änderungs- und Abschaltinformationen des tatsächlichen Anbieters; aus einer Versionsnummer folgt keine allgemeingültige Migrationsfrist.

Google AIP-180 unterscheidet Kompatibilität von Quellcode, Übertragung und Bedeutung. Die Richtlinie hilft beim Prüfen von Änderungen; sie ist keine Garantie für das Verhalten einer beliebigen fremden API.

Die Änderung mit einem ausgearbeiteten Fall beschreiben

In unserem Beispiel enthält die alte Anfrage das Feld delivery_note als Text. Die neue Version erwartet den Text unter delivery_note.text. Beide Angaben sollen dieselbe Lieferanweisung „Tor B“ transportieren. Für die Umstellung genügt deshalb weder das Ersetzen einer URL noch ein erfolgreicher Verbindungsaufbau.

Prüffrage

Festlegung im Beispiel

Was muss erhalten bleiben?

Lieferanweisung Tor B am richtigen Auftrag

Was ändert sich technisch?

Textfeld wird in eine verschachtelte Struktur übertragen

Was gilt als Erfolg?

Zielauftrag enthält die Anweisung unverändert

Was ist bei fehlendem Text zu tun?

Auftrag wie bisher ohne Lieferanweisung anlegen

Prüfen Sie zusätzlich, wie Fehler und noch laufende Verarbeitung zurückgemeldet werden. Ein anderer Antwortaufbau kann den Aufrufer treffen, obwohl die Anfrage weiterhin akzeptiert wird.

Alt und neu unter denselben Bedingungen vergleichen

Bereiten Sie in einer geeigneten Testumgebung einen normalen Auftrag und einen Fall mit fehlender Lieferanweisung vor. Vergleichen Sie die gespeicherten Zieldaten und die sichtbare Rückmeldung. Klären Sie außerdem, ob die verwendeten Zugriffsrechte beide Versionen abdecken. Echte Aufträge sollten für diesen Vergleich nicht doppelt in zwei produktive Wege gesendet werden.

Umschalten mit offenen Vorgängen abstimmen

Legen Sie fest, ab welchem Punkt neue Anfragen den neuen Weg nutzen. Bereits gesendete, noch unbestätigte Anfragen brauchen eine Zuordnung, damit eine Wiederholung nicht als neuer Auftrag behandelt wird. Vereinbaren Sie einen Rückweg für neu eintreffende Anfragen und prüfen Sie gesondert, was mit bereits geschriebenen Daten geschieht. Das Zurücksetzen einer URL macht diese Änderungen nicht rückgängig.

Die alte Version kann aus diesem Datenfluss entfernt werden, wenn alle erfassten Aufrufer umgestellt und die offenen Vorgänge zugeordnet sind. Dokumentieren Sie den tatsächlich geprüften Stand statt allein das neue Versionsetikett.

Quellen

Geschrieben von

  • Tobias KrügerRedakteur für SystemintegrationTobias Krüger beschäftigt sich bei ASES mit dem Zusammenspiel verschiedener Softwaresysteme. In seinen Beiträgen erklärt er die Anbindung von ERP, CRM und Onlineshops sowie den Umgang mit Fehlern beim Datenaustausch.

ASES folgen

Weiterlesen

Alle Beiträge

Schnittstellen & Integration mit ASES

ERP, CRM und Shop sauber verbunden