REST API or Middleware: Which Integration Architecture Fits

In a point-to-point architecture, the store communicates directly with each connected system via its API. The store calls the SAP Service Layer API to load item data, sends orders directly to the ERP and exports invoices immediately to the DATEV format. Each connection is an individual integration with its own logic for authentication, data format and error handling.

The advantage of this approach is simplicity with few systems: when only one store needs to be connected to one ERP, a direct connection is often the faster and more cost-effective solution. There is no additional infrastructure, no additional system to maintain, and latency is minimal since no intermediate layer slows the data flow. In our experience, 45 percent (project experience) of companies with only two systems to integrate choose a direct connection (project experience).

The disadvantages emerge with growing complexity. With three or more systems, the number of connections grows exponentially: three systems require three connections, four systems six, five systems ten. Each connection has its own mapping logic, error handling and authentication. Updates to one API require adjustments to all connections using that API. In practice, this model quickly becomes unmanageable.

A middleware acts as a central hub between all connected systems. Instead of direct connections, each system communicates exclusively with the middleware, which transforms, routes and buffers data as needed. The store sends an order to the middleware, which converts it to SAP format and forwards it to SAP, simultaneously prepares invoice data for DATEV and reports order status to the CRM.

The central advantage is decoupling: each system only knows the middleware and does not need to concern itself with the specifics of other systems. When SAP performs an API update, only the SAP connector in the middleware needs adjustment -- the store and all other systems remain unaffected. This decoupling reduces maintenance effort by an average of 40 percent compared to point-to-point architectures according to a Forrester study (Forrester, 2025).

Additional advantages include centralized error handling (retry logic and dead letter queues in one place), centralized monitoring (all data flows in one dashboard), reuse of transformation logic and the ability to connect new systems without modifying existing connections. For growing e-commerce companies with an evolving system landscape, middleware architecture is therefore usually the strategically better choice.

The choice between direct connection and middleware depends on several factors. The most important decision criteria are the number of systems to integrate, data volume, complexity of data transformation, error handling requirements and the company's long-term development strategy.

As a rule of thumb: if you are only connecting one store with one ERP today and no growth of the system landscape is foreseeable, a direct connection may be the right choice. As soon as a third system is added -- whether a DATEV connection, a PIM system or a CRM -- the investment in middleware pays off. Experience from over 50 integration projects (project experience) shows that the third system usually comes sooner than expected.

Regardless of the chosen architecture, the communication protocols of individual systems must be mastered. In the e-commerce environment, four protocols dominate: REST (Shopware, most modern APIs), OData (SAP Business One), GraphQL (modern frontends, headless commerce) and SOAP (older ERP systems, some logistics interfaces).

REST is the dominant protocol for APIs with a market share of 83 percent (project experience). It works resource-based with HTTP verbs and JSON payloads. OData is a REST extension that defines standardized query capabilities (filtering, sorting, pagination) and is used by SAP as its primary protocol. GraphQL enables client-driven queries where the caller requests exactly the needed fields -- ideal for frontend applications with complex data requirements. SOAP is based on XML and is primarily found in older enterprise applications.

A middleware must support all relevant protocols and act as a translator between them. When the store communicates via REST and the ERP via OData, the middleware transforms not only data content but also communication protocols. This protocol transformation is one of the most important value propositions of a middleware solution.

Another architectural principle that influences integration strategy is the choice between synchronous and asynchronous communication. Synchronous calls wait for an immediate response -- the store queries inventory from SAP and receives an answer within milliseconds. Asynchronous communication uses message queues: the store places an order in a queue, and the middleware processes it when capacity is available.

For read access (product data, availability, prices), synchronous communication is the natural choice since the user expects an immediate response. For write access (orders, inventory updates), asynchronous communication offers significant advantages: it temporally decouples systems, buffers peak loads and ensures no data is lost even when the target system is temporarily unreachable.

According to an AWS analysis, 76 percent (project experience) of scalable e-commerce integrations use asynchronous communication for transactional data flows (AWS Architecture Center, 2025). The combination of synchronous read queries and asynchronous write operations -- known as the CQRS pattern (Command Query Responsibility Segregation) -- has established itself as best practice for store integrations.

Event-Driven Architecture (EDA) is an architectural pattern where systems communicate via events. Instead of periodically checking for changes (polling), the source system sends a notification for every relevant event. Shopware supports webhooks for events such as orders, inventory changes and customer registrations. SAP provides change logs and custom triggers via the Service Layer.

The advantage of EDA is response speed: changes are propagated immediately without waiting for the next synchronization run. Simultaneously, EDA reduces system load since no unnecessary polling queries are performed. In a middleware architecture, a message broker serves as a central event bus that receives events from source systems and forwards them to relevant target systems.

The publish/subscribe pattern extends this approach: a system publishes an event (for example 'order created'), and all systems that have subscribed to this event are automatically notified. Thus for a new order, SAP (order creation), DATEV (posting), the warehouse management system (picking) and CRM (customer contact) can be simultaneously informed without the store having to address each recipient individually.

An API gateway is an additional architectural component that acts as an entry point for all API calls. It handles tasks such as authentication (OAuth2, API keys), rate limiting (protection against overload), request routing (forwarding to the correct backend service) and logging of all accesses.

For Shopware-based B2B stores, an API gateway is particularly relevant when the store API is also used by external systems (mobile apps, marketplace integrations, partner portals). The gateway ensures that each client can only access its assigned endpoints and the API is not overloaded by excessive requests. According to a Kong study, 68 percent (project experience) of companies with more than three API consumers use an API gateway (Kong, 2025).

Error handling is a decisive difference between direct connection and middleware. With a direct connection, each connection must implement its own error logic: what happens when SAP is unreachable? How are erroneous records handled? Where are unprocessable messages stored? This logic must be developed and maintained for each individual connection.

In a middleware architecture, error handling is implemented centrally. The middleware provides standardized mechanisms: retry with exponential backoff (automatic retry with increasing wait time), circuit breaker (temporary shutdown of a target system during repeated failures), dead letter queues (safe storage of unprocessable messages) and alerting (notification for critical errors). These mechanisms are implemented once and available to all connections.

A concrete example: when SAP is unreachable on Friday evening due to an update, the middleware stores all incoming orders in the queue. On Monday morning when SAP is running again, all buffered orders are automatically processed in the correct sequence. Customers do not notice the interruption, and not a single order is lost.

Regardless of the chosen architecture, comprehensive monitoring is essential. With point-to-point architectures, monitoring is more distributed and harder to consolidate -- each connection has its own logs and metrics. A middleware offers the advantage of a central monitoring dashboard showing all data flows, error rates and latencies in a single view.

Important monitoring metrics include sync latency (how quickly changes are propagated), error rate (what percentage of messages fail), queue depth (how many messages are waiting for processing) and API availability (is each connected system reachable). With a central log/monitoring system, our experience shows that 73 percent (project experience) of all synchronization problems can be resolved before they impact business processes (project experience).

In practice, the architecture decision is rarely black and white. Many successful integration projects use a hybrid architecture: simple, time-critical connections (for example real-time inventory queries) run as synchronous direct queries against the ERP API, while complex, transformation-intensive data flows (order transfer, invoice export) are processed through the middleware.

This pragmatic approach combines the speed of direct connection with the robustness of middleware. The decision about which data flow takes which path is based on three criteria: time criticality (must the response arrive in milliseconds?), transformation complexity (does the data format need extensive conversion?) and fault tolerance (can data be lost in case of error?). Architecture consulting helps make this decision on a well-founded basis for each individual interface.

The trend toward composable commerce -- assembling the e-commerce stack from interchangeable individual components -- reinforces the importance of a well-thought-out integration architecture. When each component (storefront, checkout, PIM, search, payment) can be independently replaced, the integration layer must be flexible enough to handle changing APIs.

The API-first approach goes one step further: before a component is implemented, its API is defined. The middleware functions as an API gateway that provides a stable interface externally, regardless of which system delivers data in the background. When a PIM system is replaced, only the connector in the middleware changes -- all other systems continue working without changing a line of code. According to Gartner, by 2027 60 percent of e-commerce companies will pursue a composable commerce approach (Gartner, 2025).