API: eine vereinbarte Verbindung zwischen Programmen

Eine geregelte Auskunftsstelle als Bild

Stell dir eine Auskunftsstelle mit klar beschriebenen Anliegen vor. Du stellst eine unterstützte Anfrage, lieferst die notwendigen Angaben und erhältst eine Antwort. Nicht jeder interne Schritt zur Bearbeitung muss dir bekannt sein. Eine API schafft eine vergleichbare Grenze zwischen Programmen.

Das Bild hat allerdings Grenzen: Hier handelt keine Person, die unklare Wünsche nach eigener Einschätzung auslegt. Es gelten genaue technische Regeln. Deshalb muss ein geschäftlicher Wunsch sorgfältig in die tatsächlich angebotenen Aktionen übersetzt werden. Die Schnittstelle kann nur das ermöglichen, was vorgesehen ist. Ein allgemein verständlicher Wunsch beweist noch nicht, dass eine bestimmte Anwendung ihn über ihre API erfüllen kann.

Die Schnittstelle ist noch nicht die ganze Integration

Eine vorhandene API bedeutet, dass ein System eine bestimmte Schnittstelle anbietet. Daraus folgt nicht, dass jede andere Anwendung sofort damit zusammenarbeitet. Datenintegration benötigt zusätzlich Entscheidungen darüber, welche Angaben übertragen werden, was sie bedeuten und wohin sie gehören. Ein fertiger Konnektor kann eine vorbereitete Verbindung liefern. Eine individuelle Anbindung braucht entsprechende Umsetzung.

Frage deshalb nach deinem konkreten Vorgang und nicht nur nach dem Vorhandensein einer API. Einen Kontakt zu lesen, eine Buchung anzulegen und eine Buchung zu ändern können getrennte Möglichkeiten sein. Eine bestätigte Funktion belegt nicht automatisch, dass alle anderen in der benötigten Form ebenfalls verfügbar sind.

Ein fiktiver Anbieter von Schulungen

Ein erfundener Schulungsanbieter möchte bestätigte Kursanmeldungen in seinem CRM sehen. Das Buchungssystem bietet eine Schnittstelle zum Abruf von Anmeldungen, die Kundenverwaltung eine zum Anlegen von Kontakten. Das Team muss dennoch bestimmen, wann eine Anmeldung als bestätigt gilt, woran bestehende Personen erkannt werden und was nach einer Absage passiert.

Ohne diese Regeln können doppelte Kontakte oder veraltete Teilnehmerangaben entstehen. Das Beispiel zeigt die praktische Aufgabe der API: Sie ermöglicht bestimmte Austausche. Die Organisation bleibt dafür verantwortlich, welche davon richtig und nützlich sind. Eine technisch erfolgreiche Übertragung kann geschäftlich falsch sein, wenn sie den wirklichen Stand einer Anmeldung unzutreffend abbildet.

Anbindungskarte für die technische Übergabe

Eine kleine Anforderungsanalyse wird greifbar, wenn du den Ablauf als Karte übergibst. Die folgenden Vorgaben gehören zum erfundenen Schulungsanbieter. Lass die technische Betreuung bestätigen, welche Schnittstellenfunktion jede Vorgabe erfüllt und welche Entscheidung noch offen ist. Ein Pfeil zwischen zwei Systemen ersetzt diese Zuordnung nicht.

Bei einer Änderung muss klar sein, welche Information führend ist. Eine manuell korrigierte Adresse darf beispielsweise nicht durch einen älteren Stand überschrieben werden, nur weil erneut eine Anmeldung übertragen wird.

• Auslöser: Eine Kursanmeldung ist verbindlich bestätigt. Quelle: Buchungssystem. Ziel: CRM.
• Benötigte Angaben: vereinbarte Kundenkennung, Kurskennung und Anmeldestatus. Übertragungsfrist: [fachlich benötigte Aktualität].
• Vorhandener Kontakt: über [bestätigte Kennung] zuordnen; nicht bei jeder Übertragung neu anlegen.
• Absage: Status der betroffenen Anmeldung aktualisieren; den bestehenden Kundenkontakt nicht allein deshalb löschen.
• Fehlgeschlagene Übertragung: [zuständige Rolle] erhält [Meldung] und prüft den tatsächlichen Zielstand vor einem weiteren Schreibversuch.
• Nachweis im Test: bestätigte Anmeldung einmal im richtigen Kontakt; danach Absage korrekt sichtbar. Geheimnisse und echte Kundendaten gehören nicht auf diese Karte.

Zugriffe müssen zum Zweck passen

APIs verlangen häufig Zugangsdaten oder ein anderes Verfahren zur Erkennung des aufrufenden Systems. Berechtigungen bestimmen, welche Informationen gelesen oder verändert werden dürfen. Besprich einen zur Verbindung passenden Zugriff, die Verantwortung für die Zugangsdaten und ihre Erneuerung oder Sperrung. Geheimnisse gehören nicht in öffentliche Seiten oder gewöhnliche gemeinsame Notizen.

Kläre auch den Wechsel zuständiger Mitarbeiter oder Dienstleister. Eine Anbindung über ein undokumentiertes persönliches Konto kann unerwartet ausfallen oder länger Zugriff behalten als vorgesehen. Diese Fragen sind organisatorisch lösbar. Sie sollten jedoch beantwortet sein, bevor die Verbindung zum unverzichtbaren Bestandteil täglicher Abläufe wird und jede Unterbrechung sofort Auswirkungen auf andere Personen hat.

Bei einer REST-API muss der Dienst den Zugriff für die konkrete Operation auf die betroffenen Daten prüfen. Eine erkannte Identität allein erlaubt noch nicht jede Änderung. Lass dir die benötigten und die ausdrücklich gesperrten Handlungen zeigen.

Wiederholungen dürfen keine Doppelbuchung erzeugen

Verbundene Systeme können zeitweise ausfallen, Anfragen begrenzen oder unvollständige Antworten liefern. Ein besonders wichtiger Fall: Die Buchung wurde gespeichert, aber die Bestätigung erreicht das sendende System nicht. Es kennt den Ausgang nicht. Ein erneutes Anlegen könnte dann eine zweite Buchung erzeugen.

Bei schreibenden HTTP-Aufrufen darf die Verbindung nicht einfach blind wiederholen. Für nicht idempotente Methoden beschreibt RFC 9110 eine automatische Wiederholung nur unter zusätzlichen Voraussetzungen, etwa wenn die Umsetzung gleichbleibende Wirkung sicherstellt oder erkennt, dass der erste Versuch nicht angewendet wurde. Lass diese Eigenschaft für die konkrete API bestätigen.

Verlange deshalb einen beschriebenen Wiederholungsweg, eine Meldung nach erfolglosen Versuchen und eine verantwortliche Person. Automatisierung hilft erst dann zuverlässig, wenn jemand den unklaren Fall erkennen und bearbeiten kann. Prüfe im freigegebenen Test auch die Kombination „gespeichert, aber keine Antwort“, statt nur einen vollständig unerreichbaren Dienst zu simulieren.

Prüfe eine kleine repräsentative Verbindung

Ein begrenzter Proof of Concept kann die Machbarkeit vor einer großen Beauftragung untersuchen. Nutze geeignete Beispieldaten und teste mehr als den Idealfall. Dazu gehören ein bereits vorhandener Kunde, fehlende Angaben, eine geänderte Buchung und eine unterbrochene Anfrage.

Prüfe das Ergebnis in der empfangenden Anwendung und nicht nur die Rückmeldung der Verbindung. Die zuständige Person sollte einen Fehler erkennen und bearbeiten können. Eine Vorführung belegt nur die tatsächlich geprüften Fälle. Halte offene Annahmen zu Umfang, Rechten und späteren Änderungen fest. So wird aus einem engen Experiment nicht versehentlich der vermeintliche Nachweis eines vollständig betreibbaren Dienstes.

Nach dem ersten Austausch braucht es Betreuung

Schnittstellen können sich weiterentwickeln, Zugänge können ablaufen und geschäftliche Regeln sich verändern. Jemand muss die Verbindung überwachen, Anbieterhinweise verstehen und die Zuordnung zwischen Systemen pflegen. Dokumentiere kurz Zweck, unterstützte Aktionen, verantwortliche Personen und den Umgang mit Störungen. Prüfe diese Informationen bei größeren Änderungen einer Anwendung.

Eine erste erfolgreiche Übertragung ist der Anfang und kein Beweis für unbegrenzten wartungsfreien Betrieb. Entscheidend ist, ob die Verbindung dauerhaft richtige Daten liefert, Probleme verständlich zeigt und angepasst werden kann. Dazu sollte nicht ausschließlich das Wissen der ursprünglichen Erstellerperson nötig sein. Eine nachvollziehbare Übergabe macht aus einer technischen Einzelarbeit eine verlässlich nutzbare Fähigkeit des Unternehmens.