Schnittstellen zuverlässig planen und vergleichen
Eine Verbindung zwischen zwei Programmen ist erst dann nützlich, wenn die richtigen Informationen zum richtigen Zeitpunkt ankommen. Schnittstellenentwicklung umfasst deshalb mehr als einen erfolgreichen technischen Aufruf. Entscheidend sind Datenbedeutung, Fehlerfälle und Zuständigkeiten.
Ziel des Austauschs beschreiben
Nennen Sie Ausgangs- und Zielsysteme sowie das gewünschte fachliche Ergebnis. Sollen Aufträge übernommen, Artikel aktualisiert, Dokumente bereitgestellt oder Messwerte weitergegeben werden? Klären Sie, ob Daten nur gesendet, nur empfangen oder in beide Richtungen abgeglichen werden.
Eine neue API für künftige Partner ist ein anderer Auftrag als die Verbindung bestehender Programme. Eine fehlerhafte vorhandene Schnittstelle wiederum benötigt zunächst eine begrenzte Analyse, bevor Umfang und Lösung feststehen.
| Auftrag | Erste Klärung |
|---|---|
| Bestehende Systeme verbinden | Quelle, Ziel und benötigte Vorgänge |
| Neue API bereitstellen | Künftige Nutzer, erlaubte Operationen und Beschreibung |
| Schnittstelle ändern | Version, bestehende Abläufe und erhaltenes Verhalten |
| Fehler untersuchen | Begrenzter Fall und verantwortliche Systeme |
Vorhandene Möglichkeiten und Versionen prüfen
Bekannte Programme und Versionen helfen dem Anbieter, verfügbare APIs, Dateiexporte oder andere Zugänge zu prüfen. Nicht jedes System erlaubt dieselben Objekte oder Schreibvorgänge. Zugangsvoraussetzungen, Lizenzen und Unterstützung des jeweiligen Herstellers können den Umfang beeinflussen.
Fragen Sie nach dokumentierten Operationen, Feldern und Antworten. Eine maschinenlesbare Beschreibung kann Tests und Dokumentation erleichtern, ersetzt aber nicht den Nachweis, dass die benötigten Funktionen tatsächlich verfügbar sind.
Daten und Verantwortlichkeit festlegen
Ordnen Sie jedem wichtigen Datentyp eine verantwortliche Quelle zu. Identifikatoren, Pflichtfelder, Einheiten, Status und Änderungsregeln müssen zusammenpassen. Sonst kann eine technisch erfolgreiche Übertragung fachlich falsch sein.
Bei Austausch in beide Richtungen braucht es Regeln für gleichzeitige Änderungen und Dubletten. Vereinbaren Sie, wie Löschungen und unvollständige Datensätze behandelt werden. Für die erste Anfrage genügt eine Beschreibung der Datenarten ohne echte Kundendaten.
Rhythmus, Fehler und Grenzen klären
Einzelne Aufrufe, Ereignisse und periodische Sammelübertragungen stellen unterschiedliche Anforderungen. Nennen Sie bekannte Datenmengen und Spitzen im gemeinsamen Kurztext; offene Grössen dürfen zunächst geklärt werden.
Prüfen Sie wiederholte Ereignisse, Teilerfolge, Zeitüberschreitungen und einen unterbrochenen Dienst. Wiederholungsversuche müssen begrenzt sein und dürfen nicht unbemerkt doppelte Aufträge oder zusätzliche Gebühren auslösen. Legen Sie fest, wann eine Person eingreifen soll.
Zugriffsrechte und Betrieb absichern
Ein gültiger Zugang beweist noch nicht, dass jede angeforderte Aktion oder jeder Datensatz erlaubt ist. Prüfen Sie getrennt, wer welche Daten lesen oder verändern darf. Personenbezogene Daten verlangen zudem klare Verantwortlichkeiten und einen passenden Umfang des Austauschs.
Klären Sie Betrieb, Versionswechsel, Fehlerprotokolle und Störungen mit den beteiligten Systemverantwortlichen. Protokolle sollten nur notwendige Informationen enthalten. Passwörter, Schlüssel, produktive Daten und vollständige Fehlerlogs gehören nicht in eine öffentliche Erstanfrage.
Entwicklung und laufende Kosten trennen
Die Offerte sollte Analyse, Datenzuordnung, Umsetzung, Tests und Dokumentation unterscheiden. Bei mehreren Systemen können vorhandene Verbindungen wiederverwendbar sein, müssen aber auf den konkreten Umfang geprüft werden.
Berücksichtigen Sie API-Lizenzen, nutzungsabhängige Dienste, Betrieb und spätere Änderungen. Begrenzte Aufrufe und nachvollziehbare Kostenannahmen sind besonders bei fremden Diensten wichtig. Ein erfolgreicher Test bedeutet keinen garantierten Geldbetrag für den späteren Betrieb.
| Kostenbestandteil | Im Angebot prüfen |
|---|---|
| Analyse | Verfügbare Zugänge, Daten und offene Fragen |
| Umsetzung | Zuordnung, Übertragung und Fehlerbehandlung |
| Abnahme | Beispiele, Rechteprüfungen und Dokumentation |
| Betrieb | Lizenzen, Nutzung, Betreuung und Versionswechsel |
Anfrage und Abnahmetest vorbereiten
Für die erste Einordnung reichen Ziel, beteiligte Systeme, Richtung, Datenarten, Rhythmus und gewünschte Betreuung. Beschreiben Sie bekannte Versionen, ungefähre Mengen und Sonderfälle gemeinsam in einem kurzen Text. Verwenden Sie keine Zugangsdaten oder vertraulichen Originaldateien.
Vereinbaren Sie danach einen Test mit unkritischen Beispielen: normaler Austausch, ungültige Daten, fehlende Berechtigung, Wiederholung und Unterbrechung. Prüfen Sie das fachliche Ergebnis in beiden Systemen und halten Sie Zuständigkeiten sowie Übergabe fest.
Häufige Fragen
Ist eine API dasselbe wie ein Dateiexport?
Nein. Beides kann Daten übertragen, aber Operationen, Rhythmus, Rückmeldungen und Rechte unterscheiden sich. Prüfen Sie den benötigten Ablauf.
Müssen wir ein Protokoll wie REST vorgeben?
Nicht für die erste Anfrage. Bekannte Systeme und der gewünschte Austausch reichen; vorhandene Vorgaben können Sie im Kurztext nennen.
Bedeutet ein erfolgreicher Aufruf richtige Daten?
Nicht automatisch. Prüfen Sie Zuordnung, Status und das Ergebnis im Zielsystem ebenso wie die technische Antwort.
Warum müssen Wiederholungen getestet werden?
Ein Ereignis kann erneut eintreffen oder nach einer Unterbrechung nochmals verarbeitet werden. Es muss klar sein, wie Dubletten und Teilerfolge behandelt werden.
Brauchen Anbieter unsere Passwörter zur ersten Einschätzung?
Nein. Beschreiben Sie Systeme und Datenarten. Ein später nötiger Testzugang gehört in einen gesondert vereinbarten sicheren Ablauf.
Welche Kosten folgen der Entwicklung?
Je nach Lösung Lizenzen, API-Nutzung, Betrieb, Support und Anpassungen an neue Versionen. Lassen Sie diese Positionen getrennt ausweisen.
