Zwei Programme, ein Arbeitsablauf
Die Kundenverwaltung funktioniert. Das Rechnungssystem ebenfalls. Trotzdem kommen seit dem letzten Update keine neuen Aufträge mehr an. Solche Fehler liegen häufig nicht in einer einzelnen Oberfläche, sondern an der Grenze zwischen zwei Programmen.
Eine Schnittstelle ist deshalb mehr als eine technische Verbindung. Beide Seiten müssen dieselben Erwartungen an Daten und Verhalten haben. Microsoft hat am 1. Oktober 2026 seine Arbeit mit OpenAPI, JSON Schema und zugehörigen Entwicklungswerkzeugen vorgestellt. Der Beitrag zeigt den Nutzen maschinenlesbarer Beschreibungen und überprüfbarer Schnittstellenbedingungen. [1]
Ein Vertrag zwischen zwei Programmen
Nehmen wir eine Kundenverwaltung, die einen Auftrag an die Rechnungssoftware übergibt. Welche Kundennummer gilt? Ist ein Preis netto oder brutto? Darf eine Adresse fehlen? Und was bedeutet eine erfolgreiche Antwort: nur empfangen oder bereits vollständig angelegt?
OpenAPI beschreibt HTTP-Schnittstellen in einem standardisierten, maschinenlesbaren Format. [2] Das erleichtert die gemeinsame technische Grundlage. Die fachliche Bedeutung eines Preises oder die betriebliche Verantwortung bei einem Fehler entsteht aber nicht automatisch durch das Dokument. Diese Punkte müssen die Beteiligten bewusst vereinbaren.
Auch kleine Änderungen können große Folgen haben
Ein bisher optionales Feld wird verpflichtend. Ein Datumswert bekommt ein anderes Format. Eine Statusmeldung ändert ihre Bedeutung. Für das einzelne Programm mag das plausibel wirken; die Gegenstelle kann trotzdem daran scheitern.
Unser Vorschlag ist, jede geplante Änderung auch aus Sicht des Verbrauchers zu prüfen. Können ältere Clients weiterhin arbeiten? Gibt es eine angekündigte Übergangsfrist? Wer muss die Umstellung bestätigen? Ein neuer Versionsname allein schützt keine laufende Integration.
Zusammen testen statt einzeln abhaken
Ein sinnvoller Test umfasst nicht nur den vollständig ausgefüllten Musterauftrag. Auch fehlende Daten, ungültige Werte, verweigerte Rechte und eine unterbrochene Antwort gehören dazu. Besonders wichtig ist die Frage, was nach einer Wiederholung passiert: entsteht derselbe Auftrag versehentlich zweimal?
Automatisierte Vertragsprüfungen können Unterschiede früh sichtbar machen. Ergänzend braucht es den tatsächlichen Ablauf zwischen passenden Versionen beider Anwendungen. Dass jede Seite ihre eigenen Tests besteht, beweist noch nicht, dass die gemeinsame Übergabe funktioniert.
Fehler so melden, dass jemand handeln kann
„Übertragung fehlgeschlagen“ hilft im Tagesgeschäft wenig. Besser ist eine verständliche Einordnung: Fehlt die Kundennummer, sind die Rechte abgelaufen oder ist der Dienst vorübergehend nicht erreichbar? Eine technische Vorgangskennung kann die Zuordnung zum geschützten Protokoll erleichtern.
Protokolle sollten dabei nicht unnötig vollständige Kundendaten, Zugangstoken oder vertrauliche Dokumente übernehmen. Für die Diagnose zählt eine gezielte, angemessene Nachvollziehbarkeit – nicht das unterschiedslose Sammeln sämtlicher Inhalte.
Unser Fazit
Zuverlässige Zusammenarbeit entsteht durch gepflegte Vereinbarungen, gemeinsam geprüfte Änderungen und klare Zuständigkeiten. Das ist keine einmalige Anschlussarbeit. Wer eine Schnittstelle anbietet oder nutzt, muss auch ihre Weiterentwicklung mitplanen. Dann bleibt aus zwei einzeln funktionierenden Programmen ein funktionierender Arbeitsablauf.
Quellen und Einordnung
Recherchestand: 24. Oktober 2026. Die verlinkten Hersteller- und Projektangaben sind keine eigenen Produktprüfungen. Beispiele und Empfehlungen sind als solche eingeordnet.
[1] Microsoft: OpenAPI, JSON Schema und Werkzeuge, 01.10.2026
Quelle lesen ↗
[2] OpenAPI Initiative: Spezifikation 3.2.0, Grundlagen der HTTP-API-Beschreibung
Quelle lesen ↗