API-Strategie & Schnittstellen
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.
Womit ich arbeite
REST-Design, das Bestand hat
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.
SOAP/XML-Altschnittstellen
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.
Datei-basierte Austauschformate
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.
Branchenprotokolle wie HL7
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.
Versionierung & API-Verträge
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.
Alt- und Neusysteme verbinden
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.
Und GraphQL?
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.
Belegt, nicht behauptet
- XML/SOAP im Automotive-Umfeld: Backend- und Schnittstellenentwicklung zur VIN-basierten Fahrzeugbewertung mit Anbindung externer Bewertungsdienste – auf Basis fachlicher Anforderungen und vorhandener Schnittstellenverträge
- HL7 im Klinikumfeld: mobile Patientenakte mit Verschlüsselung und HL7-Anbindung über HAPI – medizinische Informationen zwischen mobilen Anwendungen und Kliniksystem nutzbar machen
- Heterogene Payroll-Systeme: Datenmodelle unterschiedlicher Lohnsysteme vereinheitlichen und Dokumente über Webanwendung, Arbeitsplatz-Client und Hintergrunddienste verarbeiten
- Gewachsene Dokumentenplattform: bestehende Kunden- und Dokumentbestände in eine neue Webanwendung und ein überarbeitetes Datenmodell überführen
- REST- und Dateiformat-Backends: u. a. REST-Services mit Push-Anbindung hinter mobilen Apps, REST-Lizenzvalidierung mit Token-Ausgabe sowie ein Backend mit CSV-Ingest im 30-Minuten-Polling und XML-Auslieferung (JAXB)
Schnittstellen zu Maschinen, Geräten und Sensorik sind ein eigenes Kapitel – mehr dazu unter Mittelstand & Maschinenbau.
Wenn niemand mehr weiß, wie die Schnittstelle funktioniert
Der kritischste Fall ist nicht die schlechte Schnittstelle – sondern die, deren Entwickler nicht mehr da sind. Genau solche Fälle übernehme ich.
- Eigenständige Einarbeitung ohne geordnete Übergabe: aus Code, Datenverkehr und Datenbank rekonstruieren, was die Schnittstelle wirklich tut – nicht, was die alte Doku behauptet
- Systemwissen dokumentieren: Formate, Abläufe und Sonderfälle festhalten, damit das Wissen nicht wieder an einer Person hängt
- Stabilisieren, dann weiterentwickeln: erst den Betrieb sichern, dann kontrolliert modernisieren – kein Neubau als Reflex
- Auch in regulierten und technisch tiefen Domänen: Alt-Datenmodelle, XML/SOAP-, HL7- und DATEV-nahe Integrationen, bei denen fachliche Einarbeitung Teil der Aufgabe ist
Wie ich solche Übernahmen grundsätzlich angehe, beschreibe ich unter Project Rescue & Continuity.
Welche Schnittstelle bereitet Ihnen Sorgen?
Ob neue API, Altsystem-Anbindung oder eine Schnittstelle ohne Ansprechpartner –
lassen Sie uns darüber sprechen. Unverbindlich und kostenfrei.