API-Entwicklung: Systeme sauber verbinden statt verkleben

„Wir brauchen mal eben eine Schnittstelle." Dieser Satz hat schon mehr Softwareprojekte gesprengt als jede andere Anforderung. Er klingt so klein. Er ist es nie. APIs sind die Stellen, an denen dein System auf Systeme trifft, die du nicht kontrollierst — und genau dort entstehen die teuersten Überraschungen.

Dieser Beitrag erklärt aus der Praxis im Raum München, wann eine eigene API wirklich sinnvoll ist, wann sie nur Komplexität ohne Nutzen erzeugt — und woran du eine saubere Integration von einer verklebten unterscheidest. Ehrlich, ohne Buzzword-Bingo.

1. Was eine API eigentlich ist — ohne Jargon

Eine API (Application Programming Interface) ist ein Vertrag zwischen zwei Systemen: „Wenn du mich so fragst, antworte ich dir so." Nicht mehr, nicht weniger. Der Wert einer API liegt nicht in der Technik, sondern in diesem Vertrag — er macht zwei Systeme unabhängig voneinander veränderbar.

Der Gegensatz dazu ist die „Verklebung": zwei Systeme, die direkt aufeinander zugreifen, auf die Datenbank des anderen, auf interne Dateien, auf undokumentierte Verhaltensweisen. Das funktioniert — bis eines der beiden Systeme sich ändert. Dann bricht das andere mit, oft an einem Freitagnachmittag.

Eine gute API ist im Kern eine Versicherung gegen genau diesen Moment. Du bezahlst etwas mehr beim Bauen, damit beide Seiten sich später unabhängig weiterentwickeln können, ohne sich gegenseitig zu zerstören.

2. Wann eine eigene API NICHT sinnvoll ist

Bevor wir über das Wann reden, das ehrliche Wann-nicht — denn eine eigene API ist kein Selbstzweck.

Wenn es nur einen einzigen Konsumenten gibt und sich das nicht ändert. Wenn genau ein System genau einmal Daten holt, ist eine vollwertige API oft Overengineering. Ein einfacher, gut dokumentierter Datenexport reicht — und kostet einen Bruchteil.

Wenn das Zielsystem bereits eine brauchbare API hat. Sehr oft ist die richtige Antwort, die vorhandene API des ERP, CRM oder Shops sauber zu nutzen, statt eine eigene Zwischenschicht zu bauen, die nur Komplexität addiert.

Wenn die Datenmenge winzig und die Frequenz selten ist. Ein nächtlicher Abgleich von 200 Datensätzen braucht keine Echtzeit-API. Hier ist ein simpler geplanter Job robuster und billiger.

Die Faustregel: Eine eigene API lohnt sich, sobald mehrere Konsumenten, regelmäßige Änderungen oder unterschiedliche Geschwindigkeiten im Spiel sind. Sonst baust du Infrastruktur für ein Problem, das du nicht hast.

3. Die drei teuren Wahrheiten über Schnittstellen

Aus vielen Integrationsprojekten haben sich drei Wahrheiten herauskristallisiert, die im ersten Angebot fast immer unterschätzt werden.

Erstens: Fremde Systeme fallen aus. Nicht ob, sondern wann. Eine professionelle Integration behandelt den Ausfall der Gegenseite als Normalfall, nicht als Ausnahme — mit Wiederholungslogik, Warteschlangen und klaren Fehlerzuständen. Wer das weglässt, baut eine Demo, kein Produkt.

Zweitens: Datenmodelle passen nie sauber zusammen. Dein „Kunde" ist nicht der „Kunde" des ERP. Die Übersetzung zwischen zwei Datenwelten — das Mapping — ist der eigentliche, oft unsichtbare Aufwand. Hier steckt mehr Arbeit als in der eigentlichen Verbindung.

Drittens: APIs sind nie fertig. Die Gegenseite ändert ihre API, deprecatet Felder, ändert Limits. Eine Integration ist kein Bauwerk, sondern eine Beziehung, die gepflegt werden muss. Das gehört in die Folgekostenrechnung.

4. Woran du eine saubere Integration erkennst

Du musst kein Entwickler sein, um Qualität zu beurteilen. Achte auf:

• Sie überlebt einen Ausfall der Gegenseite. Fällt das ERP für eine Stunde aus, gehen keine Daten verloren — sie werden nachgeholt.
• Sie ist beobachtbar. Du siehst, ob die Schnittstelle gerade arbeitet, hängt oder Fehler produziert — ohne in Logdateien zu graben.
• Sie ist dokumentiert wie ein Vertrag. Was rein geht, was raus kommt, was bei Fehlern passiert — schriftlich, nicht im Kopf einer Person.
• Sie ist idempotent. Läuft sie versehentlich zweimal, entsteht kein doppelter Datensatz. Klingt technisch, ist im Mittelstand bares Geld.

Diese Eigenschaften sind kein Luxus. Sie sind der Unterschied zwischen einer Schnittstelle, die du vergisst, und einer, die dich jeden Monat einen Supportfall kostet.

5. API-Entwicklung im Kontext München-Mittelstand

Im Raum München sehen wir oft dieselbe Konstellation: ein gewachsenes ERP, ein CRM, vielleicht ein Online-Shop, dazwischen Menschen, die Daten manuell kopieren. Die Versuchung ist groß, sofort eine große Integrationsplattform zu kaufen. Häufig reicht eine schlanke, gut gebaute API-Schicht — exakt für die zwei, drei Wege, die wirklich wehtun.

API-Entwicklung ist selten ein eigenständiges Projekt. Sie ist fast immer Teil von etwas Größerem — einer neuen Individualsoftware, einer Modernisierung, einer Plattformeinführung. Deshalb gehört dieser Beitrag in den größeren Zusammenhang, den wir im Leitfaden zur individuellen Softwareentwicklung aufgespannt haben.

Wenn dein Schnittstellenproblem aus einem Altsystem stammt, lohnt sich ein Blick in Legacy-Modernisierung — APIs sind oft der erste, risikoärmste Schritt, ein Altsystem zu entschärfen. Und wenn du dich fragst, ob dein Vorhaben besser als Festpreis oder iterativ läuft: Festpreis vs. agil beantwortet genau das ehrlich.

Mehr zu unserem Vorgehen findest du auf der Seite zur individuellen Software- und App-Entwicklung.

Fazit

Eine API ist kein technisches Detail, sondern ein Vertrag, der zwei Systeme unabhängig hält. Sie ist nicht immer die richtige Antwort — aber wenn sie es ist, entscheidet ihre Qualität über die Betriebskosten der nächsten Jahre.

Quellen

Dieser Beitrag beruht überwiegend auf eigener Projekterfahrung aus Integrations- und API-Projekten im Raum München. Wo wir auf etabliertes Architekturwissen verweisen (direkter Datenbankzugriff als Antipattern, Schnittstelle als risikoarmer erster Modernisierungsschritt), sind unten die Primärquellen verlinkt.

• Eigene Projekterfahrung aus Integrations- und API-Projekten für mittelständische Unternehmen im Raum München
• Martin Fowler: Integration Database — warum der direkte Griff in fremde Datenbanken Systeme verklebt
• Martin Fowler: Strangler Fig Application — eine API-Schicht als risikoarmer erster Schritt
• Leitfaden: individuelle Softwareentwicklung — der größere Zusammenhang
• Legacy-Modernisierung — APIs als risikoarmer erster Schritt
• Festpreis vs. agil — Vorgehensmodell für Integrationsprojekte