Schnittstellen sind seit vielen Jahren mein Alltag – auch die unschönen: SOAP-Dienste ohne aktuelle Doku, gewachsene XML-Formate, CSV-Lieferungen per festem Zeitplan, Branchenprotokolle mit eigenen Regeln.
Ich entwerfe neue APIs sauber und versionierbar – und ich übernehme bestehende Schnittstellen, auch wenn deren ursprüngliche Entwickler längst weg sind.
Ressourcen statt Methodensammlung, konsistente Fehlerformate, saubere Authentifizierung, nachvollziehbare Verträge. Ich baue seit Jahren REST-APIs für Backends hinter mobilen Apps, Fachanwendungen und Lizenzsystemen – dokumentiert so, dass auch der nächste Entwickler damit arbeiten kann.
Viele geschäftskritische Dienste sprechen weiterhin SOAP und XML – das ist kein Makel, sondern Realität. Ich binde solche Dienste an, halte sie am Laufen und kapsle sie so, dass ihre Eigenheiten nicht Ihre neue Software durchdringen: WSDL, XSD, Namespaces und Sonderfälle inklusive.
CSV-Importe im Polling-Takt, feste Satzformate, Export-Verzeichnisse, DATEV-nahe Datenstrukturen: Datenaustausch per Datei ist in vielen Branchen gelebte Praxis. Entscheidend sind Validierung, Fehlerbehandlung und Wiederanlauf – eine halb verarbeitete Lieferung darf keinen inkonsistenten Zustand hinterlassen.
Manche Domänen haben eigene Protokollwelten. Im Klinikumfeld habe ich eine HL7-Anbindung (HAPI) an eine Klinik umgesetzt – Teil einer verschlüsselten mobilen Patientenakte, bei der Nachrichtenformate, Datenschutz und Fehlertoleranz zusammen gedacht werden mussten.
Eine API ist ein Versprechen an ihre Nutzer. Ich plane Versionierung von Anfang an: abwärtskompatible Erweiterungen bevorzugen, Breaking Changes explizit versionieren, Abkündigungen mit Übergangsfristen kommunizieren. So bleiben Apps, Partner und Altsysteme angebunden, während sich die API weiterentwickelt.
Der häufigste Fall: Ein bewährtes Altsystem soll mit einer neuen Anwendung zusammenarbeiten. Ich baue die Brücke – Adapter und Anti-Corruption-Layer, die das Alte kapseln statt es zu verteilen. So kann die Modernisierung schrittweise laufen, ohne den Betrieb zu gefährden.
GraphQL hat seinen Platz: viele unterschiedliche Clients, flexible Lesemodelle, Frontends, die ihren Datenbedarf selbst bestimmen sollen. Für die meisten Integrationsaufgaben im Mittelstand ist es aber nicht der erste Griff – eine gut geschnittene REST-API mit klaren Verträgen ist einfacher zu betreiben, zu cachen und abzusichern.
Meine ehrliche Einordnung: Ich empfehle GraphQL dort, wo es ein reales Problem löst – und rate ab, wo es nur Komplexität in Schema-Design, Berechtigungen und Betrieb hinzufügt. Die Technologie-Entscheidung folgt Ihrem Anwendungsfall, nicht dem Hype-Zyklus.
Schnittstellen zu Maschinen, Geräten und Sensorik sind ein eigenes Kapitel – mehr dazu unter Mittelstand & Maschinenbau.
Der kritischste Fall ist nicht die schlechte Schnittstelle – sondern die, deren Entwickler nicht mehr da sind. Genau solche Fälle übernehme ich.
Wie ich solche Übernahmen grundsätzlich angehe, beschreibe ich unter Project Rescue & Continuity.
Ob neue API, Altsystem-Anbindung oder eine Schnittstelle ohne Ansprechpartner –
lassen Sie uns darüber sprechen. Unverbindlich, 30 Minuten, kostenfrei.