Ein Auftrag wird im Shop angenommen, anschließend von Hand in die Warenwirtschaft übertragen und am nächsten Morgen für den Versand erneut exportiert. Jeder Übergang kostet Aufmerksamkeit. Noch problematischer wird es, wenn eine Korrektur nur in einem der beteiligten Systeme ankommt. Schnittstellen sollen solche Brüche verkleinern. Dafür müssen sie mehr leisten als Daten von einer Adresse zur anderen zu senden.

Eine API ist eine definierte Möglichkeit, Funktionen oder Daten eines Systems zu verwenden. Sie beschreibt beispielsweise, wie ein Auftrag angelegt oder ein Lieferstatus abgefragt werden kann. Im Unternehmensalltag entscheidet die Qualität dieser Vereinbarung darüber, ob eine Integration nachvollziehbar bleibt. Ein erreichbarer Endpunkt ist erst der Anfang; Fachregeln, Zugriffsschutz und Fehlerbehandlung gehören ebenso dazu.

Was REST bedeutet und was nicht

REST bezeichnet einen Architekturstil für verteilte Systeme. Viele Webschnittstellen orientieren sich daran, indem sie Ressourcen über URLs zugänglich machen und die Bedeutung der HTTP-Methoden nutzen. Eine Ressource kann ein Auftrag oder eine Kundenadresse sein. JSON ist dabei ein verbreitetes Datenformat, aber weder Pflicht für REST noch ein Beleg für eine durchdachte API.

HTTP unterscheidet unter anderem das Lesen mit GET, das Ersetzen mit PUT und verschiedene weitere Operationen. Für Integrationen sind ihre Eigenschaften wichtig: Eine als sicher definierte Abfrage soll keine fachlichen Änderungen auslösen. Bei idempotenten Operationen soll die wiederholte Ausführung denselben beabsichtigten Effekt haben wie eine einzelne Ausführung. Die HTTP-Spezifikation RFC 9110 erläutert diese Semantik. Daraus folgt nicht, dass jeder beliebige Endpunkt sie korrekt umsetzt.

Zuerst die Datenverantwortung klären

Wenn zwei Systeme dieselbe Kundenadresse verändern dürfen, entsteht ein Konflikt, den ein Transportprotokoll nicht lösen kann. Für jedes wichtige Objekt sollte deshalb feststehen, welches System die führende Quelle ist. Andere Anwendungen übernehmen gegebenenfalls ausgewählte Felder oder halten eine ausdrücklich gekennzeichnete Kopie.

Ein fiktives Beispiel: Die Warenwirtschaft verantwortet Artikelnummer und Verkaufsstatus, während ein Produktinformationssystem redaktionelle Beschreibungen verwaltet. Der Shop führt beide Informationen zusammen. Änderungen am Text dürfen dann nicht versehentlich eine abweichende Artikelnummer zurückschreiben. Eine solche Zuständigkeitsmatrix ist oft wertvoller als ein besonders umfangreiches Austauschformat.

Eindeutige Schlüssel statt Namensvergleiche

Bezeichnungen ändern sich, Schreibweisen variieren und zwei Personen können denselben Namen haben. Beziehungen sollten deshalb über stabile Kennungen hergestellt werden. Außerdem muss dokumentiert sein, zu welchem System die Kennung gehört. Eine interne Datenbanknummer ist nicht automatisch eine geeignete externe Referenz. Bei einer Migration oder Zusammenführung können zusätzliche Zuordnungstabellen erforderlich werden.

Ein Schnittstellenvertrag braucht konkrete Beispiele

Die Beschreibung einer API sollte Pflichtfelder, Datentypen, zulässige Werte, Zeitangaben und Fehlerfälle enthalten. Eine Zeichenfolge für einen Betrag wirft Fragen nach Währung und Dezimaldarstellung auf. Bei Terminen sind Zeitzone und Bedeutung zu klären: Ist ein Lieferdatum ein Kalendertag oder ein genauer Zeitpunkt?

Beispieldatensätze sollten einen normalen Vorgang, eine Korrektur und einen ungültigen Datensatz zeigen. Besonders wertvoll sind automatisch prüfbare Verträge und gemeinsame Tests. Ändert ein Anbieter einen Statuswert, muss die empfangende Anwendung erkennen können, ob sie ihn verarbeiten darf. Unbekannte Werte stillschweigend als Standardfall zu behandeln, kann falsche Entscheidungen auslösen.

Abfrage oder Ereignis?

Beim regelmäßigen Abruf fragt ein System in festgelegten Abständen nach Änderungen. Das ist verständlich, kann aber unnötige Last oder Verzögerungen verursachen. Ein Ereignisverfahren informiert die Gegenstelle über einen eingetretenen Vorgang, häufig über einen Webhook. Die Benachrichtigung sollte klar unterscheiden, ob sie nur eine Änderung meldet oder bereits die verbindlichen Daten enthält.

Ein Webhook ist keine Garantie für einmalige oder geordnete Zustellung. Netzfehler, Wiederholungen und Verzögerungen müssen berücksichtigt werden. Eine Anwendung kann beispielsweise die Ereigniskennung speichern, doppelte Nachrichten erkennen und den aktuellen Stand bei Bedarf erneut abrufen. Entscheidend ist, dass die fachliche Verarbeitung auch nach einer Unterbrechung nachvollziehbar fortgesetzt werden kann.

Doppelte Übertragung ist ein normaler Fehlerfall

Stellen Sie sich vor, das Zielsystem hat einen Auftrag angelegt, aber die Bestätigung geht unterwegs verloren. Das Quellsystem weiß dann nicht, ob die Anlage erfolgreich war. Ein unbedachter Wiederholungsversuch kann denselben Auftrag erneut erzeugen. Für schreibende Vorgänge braucht es deshalb eine verlässliche Strategie zur Wiederholung.

Je nach API kommen stabile externe Vorgangskennungen, Idempotenzschlüssel oder eine gezielte Statusabfrage infrage. Ein Schlüssel muss zur konkreten Operation und ihrem Inhalt passen. Außerdem sollte klar sein, wie lange das Ziel ihn berücksichtigt. Eine Schnittstelle, die im Erfolgsfall funktioniert, ist noch nicht betriebstauglich, wenn diese Unsicherheit unbehandelt bleibt.

Anmeldung ersetzt keine Berechtigungsprüfung

HTTPS schützt die Übertragung, und ein Token kann einen aufrufenden Dienst identifizieren. Trotzdem muss die Anwendung bei jedem Zugriff prüfen, ob dieser Dienst genau das angeforderte Objekt lesen oder verändern darf. Die OWASP API Security Top 10 beschreibt fehlende Berechtigungsprüfung auf Objektebene als eigenes Risiko. Eine schwer erratbare Kennung ist kein Ersatz für diese Prüfung.

Zugänge sollten auf den benötigten Umfang begrenzt, sicher gespeichert und austauschbar sein. Technische Konten brauchen verantwortliche Personen und geregelte Laufzeiten. Geheimnisse gehören weder in öffentliche Quellcodedateien noch in ungeschützte Protokolle. Zusätzlich helfen Begrenzungen für Anfrageraten und Datenmengen, damit eine fehlerhafte Integration nicht die gesamte Anwendung beeinträchtigt.

Fehler sichtbar und bearbeitbar machen

Ein gutes Fehlerprotokoll verbindet technische Informationen mit einem fachlichen Bezug. Beschäftigte sollten erkennen können, welcher Auftrag betroffen ist und ob eine Korrektur erforderlich wird. Gleichzeitig dürfen Protokolle keine unnötigen personenbezogenen Inhalte, Zugangstoken oder vollständigen vertraulichen Dokumente enthalten.

Für vorübergehende Fehler kann eine begrenzte Wiederholung mit wachsendem Abstand sinnvoll sein. Fachlich ungültige Daten werden dadurch dagegen nicht richtig. Sie gehören in eine bearbeitbare Fehlerliste mit klarer Zuständigkeit. Überwachungsregeln sollten außerdem melden, wenn längere Zeit keine Daten mehr eintreffen. Ein Prozess kann stillstehen, ohne einen einzelnen sichtbaren Fehler auszugeben.

Änderungen gemeinsam beherrschen

Schnittstellen entwickeln sich weiter. Zusätzliche optionale Felder sind häufig leichter verträglich als umbenannte Pflichtfelder oder veränderte Bedeutungen. Eine Versionsnummer allein verhindert keine Störung. Nötig sind ein angekündigter Übergang, Tests mit der Gegenstelle und eine vereinbarte Frist für Anpassungen.

Bei der Abnahme sollten absichtlich Unterbrechungen, doppelte Nachrichten und fehlende Berechtigungen getestet werden. Ebenso wichtig ist ein Datenabgleich nach dem Wiederanlauf. Stimmen Mengen und Status in beiden Systemen überein? Erst diese Prüfungen zeigen, ob die Integration den gesamten Vorgang absichert und nicht nur eine erfolgreiche Einzelanfrage.

Eine kleine Abnahmematrix für die Integration

Vor dem Start sollten beide beteiligten Teams dieselben Situationen prüfen. Ein gültiger Auftrag wird einmal übertragen und erscheint genau einmal im Ziel. Anschließend wird derselbe Vorgang erneut gesendet. Das erwartete Verhalten ist ausdrücklich festgelegt: vorhandenen Zustand bestätigen, kontrolliert aktualisieren oder mit verständlicher Meldung ablehnen. Die Wiederholung darf nicht zufällig einen zweiten Auftrag erzeugen.

Danach folgen ungültige und unberechtigte Anfragen. Ein fehlendes Pflichtfeld soll eine verständliche Rückmeldung liefern und keine unvollständige Teilbuchung hinterlassen. Ein technisch angemeldeter Dienst ohne passende Objektberechtigung darf keine vertraulichen Daten erhalten. Außerdem wird geprüft, welche Informationen die Fehlermeldung selbst offenlegt. Interne Zugangsdaten oder vollständige Abfragen gehören nicht in öffentliche Antworten.

Ein weiterer Test unterbricht die Verbindung nach der Verarbeitung, aber vor der Bestätigung. Genau dieser Fall zeigt, ob Statusabfrage und Wiederholung zusammen funktionieren. Nach dem Wiederanlauf werden die fachlichen Ergebnisse verglichen. Nicht nur die Zahl erfolgreicher HTTP-Antworten zählt, sondern der Zustand beider Systeme.

Die Ergebnisse werden mit der getesteten Version und den verwendeten Beispieldaten dokumentiert. Bei einer späteren Änderung können dieselben Fälle erneut ausgeführt werden. So entsteht ein kleiner gemeinsamer Vertrag, der auch dann verständlich bleibt, wenn die ursprünglichen Entwicklerinnen oder Entwickler nicht mehr unmittelbar am Projekt beteiligt sind.

Vernetzung mit klarer Verantwortung

Eine belastbare Schnittstelle verbindet technische Regeln mit fachlicher Zuständigkeit. Sie definiert Datenverantwortung, Wiederholungen, Fehlerbearbeitung und Änderungen. Dieser Aufwand ist kleiner, wenn er bereits im Konzept berücksichtigt wird, statt nach der ersten doppelten Bestellung ergänzt zu werden.

GRITTMANN kann vorhandene Datenflüsse aufnehmen und begrenzte Integrationen für individuelle Anwendungen konzipieren. Dabei sollte ein konkreter Vorgang als Pilot dienen. Wie solche Verbindungen eine individuelle Warenwirtschaft ergänzen können, zeigt unser ausdrücklich fiktives Anwendungsbeispiel.

Quellen und weiterführende Dokumentation

Fachliche Grundlagen und ergänzende Hinweise der jeweiligen Herausgeber. Links zuletzt geprüft am 27.03.2026.