REST-API oder Middleware: Welche Integrationsarchitektur passt

Bei einer Punkt-zu-Punkt-Architektur kommuniziert der Shop direkt mit jedem angebundenen System über dessen API. Der Shop ruft die SAP Service Layer API auf, um Artikeldaten zu laden, sendet Bestellungen direkt an das ERP und exportiert Rechnungen unmittelbar in das DATEV-Format. Jede Verbindung ist eine individuelle Integration mit eigener Logik für Authentifizierung, Datenformat und Fehlerbehandlung.

Der Vorteil dieses Ansatzes liegt in der Einfachheit bei wenigen Systemen: Wenn nur ein Shop mit einem ERP verbunden werden soll, ist eine Direktanbindung oft die schnellere und kostengünstigere Lösung. Es gibt keine zusätzliche Infrastruktur, kein zusätzliches System, das gewartet werden muss, und die Latenz ist minimal, da keine Zwischenschicht den Datenfluss verlangsamt. Erfahrungsgemäß wählen 45 Prozent (Projekterfahrung) der Unternehmen mit nur zwei zu integrierenden Systemen eine Direktanbindung (Projekterfahrung).

Die Nachteile zeigen sich mit wachsender Komplexität. Bei drei oder mehr Systemen steigt die Anzahl der Verbindungen exponentiell: Drei Systeme erfordern drei Verbindungen, vier Systeme sechs, fünf Systeme zehn. Jede Verbindung hat eigene Mapping-Logik, eigene Fehlerbehandlung und eigene Authentifizierung. Updates an einer API erfordern Anpassungen an allen Verbindungen, die diese API nutzen. In der Praxis wird dieses Modell schnell unbeherrschbar.

Eine Middleware fungiert als zentrale Drehscheibe zwischen allen angebundenen Systemen. Statt direkter Verbindungen kommuniziert jedes System ausschließlich mit der Middleware, die Daten transformiert, routet und bei Bedarf zwischenspeichert. Der Shop sendet eine Bestellung an die Middleware, die sie in das SAP-Format konvertiert und an SAP weiterleitet, gleichzeitig die Rechnungsdaten für DATEV aufbereitet und den Bestellstatus an das CRM meldet.

Der zentrale Vorteil ist die Entkopplung: Jedes System kennt nur die Middleware und muss sich nicht um die Eigenheiten der anderen Systeme kümmern. Wenn SAP ein API-Update durchführt, muss nur der SAP-Konnektor in der Middleware angepasst werden -- der Shop und alle anderen Systeme bleiben unberührt. Diese Entkopplung reduziert den Wartungsaufwand laut einer Studie von Forrester um durchschnittlich 40 Prozent gegenüber Punkt-zu-Punkt-Architekturen (Forrester, 2025).

Weitere Vorteile umfassen die zentrale Fehlerbehandlung (Retry-Logik und Dead Letter Queues an einer Stelle), das zentrale Monitoring (alle Datenflüsse in einem Dashboard), die Wiederverwendung von Transformationslogik und die Möglichkeit, neue Systeme anzubinden, ohne bestehende Verbindungen zu verändern. Für wachsende E-Commerce-Unternehmen mit einer sich entwickelnden Systemlandschaft ist die Middleware-Architektur daher meist die strategisch bessere Wahl.

Die Wahl zwischen Direktanbindung und Middleware hängt von mehreren Faktoren ab. Die wichtigsten Entscheidungskriterien sind die Anzahl der zu integrierenden Systeme, das Datenvolumen, die Komplexität der Datentransformation, die Anforderungen an Fehlerbehandlung und die langfristige Entwicklungsstrategie des Unternehmens.

Als Faustregel gilt: Wenn Sie heute nur einen Shop mit einem ERP verbinden und kein Wachstum der Systemlandschaft absehbar ist, kann eine Direktanbindung die richtige Wahl sein. Sobald ein drittes System hinzukommt -- sei es eine DATEV-Anbindung, ein PIM-System oder ein CRM -- lohnt sich die Investition in eine Middleware. Die Erfahrung aus über 50 Integrationsprojekten (Projekterfahrung) zeigt, dass das dritte System meist schneller kommt als gedacht.

Unabhängig von der gewählten Architektur müssen die Kommunikationsprotokolle der einzelnen Systeme beherrscht werden. Im E-Commerce-Umfeld sind vier Protokolle dominant: REST (Shopware, die meisten modernen APIs), OData (SAP Business One), GraphQL (moderne Frontends, Headless Commerce) und SOAP (ältere ERP-Systeme, manche Logistikschnittstellen).

REST ist mit einem Marktanteil von 83 Prozent (Projekterfahrung) das dominierende Protokoll für APIs. Es arbeitet ressourcenbasiert mit HTTP-Verben und JSON-Payloads. OData ist eine Erweiterung von REST, die standardisierte Abfragemöglichkeiten (Filterung, Sortierung, Paginierung) definiert und von SAP als primäres Protokoll genutzt wird. GraphQL ermöglicht client-gesteuerte Abfragen, bei denen der Aufrufer exakt die benötigten Felder anfordert -- ideal für Frontend-Anwendungen mit komplexen Datenanforderungen. SOAP basiert auf XML und ist vor allem in älteren Unternehmensanwendungen verbreitet.

Eine Middleware muss alle relevanten Protokolle unterstützen und als Übersetzer zwischen ihnen fungieren. Wenn der Shop via REST kommuniziert und das ERP via OData, transformiert die Middleware nicht nur die Dateninhalte, sondern auch die Kommunikationsprotokolle. Diese Protokoll-Transformation ist einer der wichtigsten Mehrwerte einer Middleware-Lösung.

Ein weiteres Architekturprinzip, das die Integrationsstrategie beeinflusst, ist die Wahl zwischen synchroner und asynchroner Kommunikation. Synchrone Aufrufe warten auf eine sofortige Antwort -- der Shop fragt den Lagerbestand bei SAP ab und erhält innerhalb von Millisekunden eine Antwort. Asynchrone Kommunikation nutzt Message Queues: Der Shop stellt eine Bestellung in eine Queue, und die Middleware verarbeitet sie, sobald Kapazität verfügbar ist.

Für Lesezugriffe (Produktdaten, Verfügbarkeiten, Preise) ist synchrone Kommunikation die natürliche Wahl, da der Nutzer eine sofortige Antwort erwartet. Für Schreibzugriffe (Bestellungen, Bestandsupdates) bietet asynchrone Kommunikation erhebliche Vorteile: Sie entkoppelt die Systeme zeitlich, puffert Lastspitzen ab und stellt sicher, dass keine Daten verloren gehen, selbst wenn das Zielsystem temporär nicht erreichbar ist.

Laut einer Analyse von AWS nutzen 76 Prozent der skalierbaren E-Commerce-Integrationen asynchrone Kommunikation für transaktionale Datenflüsse (AWS Architecture Center, 2025). Die Kombination aus synchronen Leseabfragen und asynchronen Schreibvorgängen -- bekannt als CQRS-Muster (Command Query Responsibility Segregation) -- hat sich als Best Practice für Shop-Integrationen etabliert.

Event-Driven Architecture (EDA) ist ein Architekturmuster, bei dem Systeme über Ereignisse kommunizieren. Statt periodisch nach Änderungen zu fragen (Polling), sendet das Quellsystem bei jedem relevanten Ereignis eine Benachrichtigung. Shopware unterstützt Webhooks für Events wie Bestellungen, Bestandsänderungen und Kundenregistrierungen. SAP bietet über die Service Layer Change-Logs und individuelle Trigger.

Der Vorteil von EDA ist die Reaktionsgeschwindigkeit: Änderungen werden sofort propagiert, ohne auf den nächsten Synchronisationslauf warten zu müssen. Gleichzeitig reduziert EDA die Systemlast, da keine unnötigen Polling-Abfragen durchgeführt werden. In einer Middleware-Architektur dient ein Message Broker als zentraler Event-Bus, der Ereignisse von Quellsystemen empfängt und an die relevanten Zielsysteme weiterleitet.

Das Publish/Subscribe-Muster erweitert diesen Ansatz: Ein System veröffentlicht ein Event (zum Beispiel 'Bestellung erstellt'), und alle Systeme, die dieses Event abonniert haben, werden automatisch benachrichtigt. So können bei einer neuen Bestellung gleichzeitig SAP (Auftragsanlage), DATEV (Buchung), das Lagerverwaltungssystem (Kommissionierung) und das CRM (Kundenkontakt) informiert werden, ohne dass der Shop jeden Empfänger einzeln ansprechen muss.

Ein API-Gateway ist eine zusätzliche Architekturkomponente, die als Eingangstor für alle API-Aufrufe fungiert. Es übernimmt Aufgaben wie Authentifizierung (OAuth2, API-Keys), Rate Limiting (Schutz vor Überlastung), Request-Routing (Weiterleitung an den richtigen Backend-Service) und Logging aller Zugriffe.

Für Shopware-basierte B2B-Shops ist ein API-Gateway besonders relevant, wenn die Shop-API auch von externen Systemen (Mobile Apps, Marktplatz-Integrationen, Partner-Portale) genutzt wird. Das Gateway stellt sicher, dass jeder Client nur auf die ihm zugewiesenen Endpunkte zugreifen kann und die API nicht durch übermäßige Anfragen überlastet wird. Laut einer Studie von Kong nutzen 68 Prozent (Projekterfahrung) der Unternehmen mit mehr als drei API-Konsumenten ein API-Gateway (Kong, 2025).

Die Fehlerbehandlung ist ein entscheidender Unterschied zwischen Direktanbindung und Middleware. Bei einer Direktanbindung muss jede Verbindung ihre eigene Fehlerlogik implementieren: Was passiert, wenn SAP nicht erreichbar ist? Wie werden fehlerhafte Datensätze behandelt? Wo werden nicht verarbeitbare Nachrichten gespeichert? Diese Logik muss für jede einzelne Verbindung entwickelt und gewartet werden.

In einer Middleware-Architektur wird die Fehlerbehandlung zentral implementiert. Die Middleware bietet standardisierte Mechanismen: Retry mit Exponential Backoff (automatische Wiederholung mit ansteigender Wartezeit), Circuit Breaker (temporäre Abschaltung eines Zielsystems bei wiederholten Fehlern), Dead Letter Queues (sichere Ablage nicht verarbeitbarer Nachrichten) und Alerting (Benachrichtigung bei kritischen Fehlern). Diese Mechanismen werden einmal implementiert und stehen allen Verbindungen zur Verfügung.

Ein konkretes Beispiel: Wenn SAP am Freitagabend aufgrund eines Updates nicht erreichbar ist, speichert die Middleware alle eingehenden Bestellungen in der Queue. Am Montagmorgen, wenn SAP wieder läuft, werden alle gepufferten Bestellungen automatisch in der richtigen Reihenfolge verarbeitet. Kunden bemerken die Unterbrechung nicht, und keine einzige Bestellung geht verloren.

Unabhängig von der gewählten Architektur ist ein umfassendes Monitoring essenziell. Bei Punkt-zu-Punkt-Architekturen ist das Monitoring verteilter und schwieriger zu konsolidieren -- jede Verbindung hat ihre eigenen Logs und Metriken. Eine Middleware bietet den Vorteil eines zentralen Monitoring-Dashboards, das alle Datenflüsse, Fehlerquoten und Latenzen in einer Übersicht zeigt.

Wichtige Monitoring-Metriken umfassen die Sync-Latenz (wie schnell werden Änderungen propagiert), die Fehlerrate (wie viel Prozent der Nachrichten scheitern), die Queue-Tiefe (wie viele Nachrichten warten auf Verarbeitung) und die API-Verfügbarkeit (ist jedes angebundene System erreichbar). Mit einem zentralen Log-/Monitoring-System lassen sich erfahrungsgemäß 73 Prozent (Projekterfahrung) aller Synchronisationsprobleme beheben, bevor sie sich auf Geschäftsprozesse auswirken (Projekterfahrung).

In der Praxis ist die Architekturentscheidung selten schwarz-weiß. Viele erfolgreiche Integrationsprojekte nutzen eine hybride Architektur: Einfache, zeitkritische Verbindungen (zum Beispiel Echtzeit-Bestandsabfragen) laufen als synchrone Direktabfragen gegen die ERP-API, während komplexe, transformationsintensive Datenflüsse (Bestellübergabe, Rechnungsexport) über die Middleware verarbeitet werden.

Dieser pragmatische Ansatz kombiniert die Geschwindigkeit der Direktanbindung mit der Robustheit der Middleware. Die Entscheidung, welcher Datenfluss welchen Weg nimmt, basiert auf drei Kriterien: Zeitkritikalität (muss die Antwort in Millisekunden vorliegen?), Transformationskomplexität (muss das Datenformat umfangreich konvertiert werden?) und Fehlertoleranz (dürfen Daten bei einem Fehler verloren gehen?). Die Architekturberatung hilft, diese Entscheidung für jede einzelne Schnittstelle fundiert zu treffen.

Der Trend zu Composable Commerce -- also der Zusammenstellung des E-Commerce-Stacks aus austauschbaren Einzelkomponenten -- verstärkt die Bedeutung einer durchdachten Integrationsarchitektur. Wenn jede Komponente (Storefront, Checkout, PIM, Search, Payment) unabhängig ausgetauscht werden kann, muss die Integrationsschicht flexibel genug sein, um mit wechselnden APIs umzugehen.

Der API-First-Ansatz geht noch einen Schritt weiter: Bevor eine Komponente implementiert wird, wird ihre API definiert. Die Middleware fungiert dabei als API-Gateway, das nach außen eine stabile Schnittstelle bietet, unabhängig davon, welches System die Daten im Hintergrund liefert. Wenn ein PIM-System ausgetauscht wird, ändert sich nur der Konnektor in der Middleware -- alle anderen Systeme arbeiten weiter, ohne eine Codezeile zu ändern. Laut Gartner werden bis 2027 60 Prozent (Projekterfahrung) der E-Commerce-Unternehmen einen Composable-Commerce-Ansatz verfolgen (Gartner, 2025).