14. Juli 2026 · von T. Kalayci
Eine der ersten Fragen, die uns Kunden beim Aufbau eines SAP Kundenportals stellen: Sollen wir SAP per REST API oder per SOAP API anbinden? Beide Varianten funktionieren, aber sie passen nicht in jeder Situation gleich gut – und die falsche Wahl kann später teure Nacharbeit bedeuten, etwa wenn eine als "schnell" geplante Schnittstelle sich als zu langsam für Echtzeit-Anforderungen herausstellt. Ein Überblick, wie wir diese Entscheidung in unseren Projekten treffen.
REST API ist heute der Standard für moderne Webportale: schlank, zustandslos, leicht zu testen und gut geeignet für Echtzeit-Abfragen wie Lagerbestände, Preise oder Bestellstatus. Die meisten aktuellen SAP-Systeme (z. B. S/4HANA) bieten dafür eigene REST-Schnittstellen an, über die ein Kundenportal Daten direkt und schnell abrufen kann. SAP nutzt dabei häufig den offenen Standard OData (Open Data Protocol) – eine auf REST aufbauende Spezifikation, mit der sich Geschäftsdaten strukturiert abfragen und filtern lassen, ohne für jede Abfrage eine eigene Schnittstelle programmieren zu müssen. Einen Überblick über die verfügbaren SAP-Schnittstellen bietet der offizielle SAP Business Accelerator Hub.
SOAP API (Simple Object Access Protocol) ist älter, aber in vielen gewachsenen SAP-Landschaften nach wie vor im Einsatz – gerade bei klassischen SAP-ECC-Systemen, die seit Jahren produktiv laufen und (noch) keine moderne REST-Schnittstelle bereitstellen. SOAP ist strenger strukturiert und eignet sich gut für Prozesse, bei denen Zuverlässigkeit und ein festes Nachrichtenformat wichtiger sind als Geschwindigkeit, etwa bei Finanzbuchungen oder Stammdatenabgleichen. Viele ältere SAP-Landschaften bringen SOAP-Schnittstellen über klassische RFC-Bausteine (Remote Function Call) und BAPIs (Business Application Programming Interfaces) mit, die oft schon Jahrzehnte im produktiven Einsatz sind – hier lohnt sich selten eine komplette Neuentwicklung, sondern eine gezielte Anbindung an das, was bereits stabil läuft.
Zusammengefasst im direkten Vergleich:
| Kriterium | REST / OData | SOAP |
|---|---|---|
| Typische SAP-Systeme | S/4HANA, moderne Cloud-Systeme | Klassisches SAP ECC, gewachsene Altsysteme |
| Geschwindigkeit | Schnell, geringes Datenformat-Overhead | Langsamer, umfangreicheres XML-Format |
| Gut geeignet für | Echtzeit-Abfragen: Bestand, Preise, Status | Zuverlässige Prozesse: Buchungen, Stammdaten |
| Einrichtungsaufwand | Meist bereits vorhanden, schnell nutzbar | Oft bereits vorhanden, aber komplexer im Aufbau neuer Services |
In der Praxis ist die Antwort deshalb selten „nur REST“ oder „nur SOAP“, sondern eine bewusste Entscheidung pro Anwendungsfall: Was bietet das jeweilige ERP-System bereits an, und wofür wird die Schnittstelle konkret gebraucht? Bei einem SAP-HR-Portal etwa sind es oft Mischformen – Stammdaten und Genehmigungsworkflows über die vorhandene SOAP-Schnittstelle, Echtzeit-Dashboards für Vorgesetzte über eine neu angelegte REST- oder OData-Schnittstelle. Auch caniasERP lässt sich über beide Wege anbinden – hier prüfen wir projektbezogen, welche Schnittstelle das System bereits bereitstellt, bevor wir eine neue aufsetzen.
Ein oft unterschätzter Zeitfaktor: Ist die passende Schnittstelle im ERP-System bereits vorhanden und dokumentiert, lässt sich die Anbindung häufig in wenigen Tagen umsetzen. Fehlt sie oder ist sie nur unzureichend dokumentiert, kann allein die Analyse und Abstimmung mit der internen IT mehrere Wochen dauern – noch bevor die eigentliche Entwicklung beginnt. Neben Geschwindigkeit und Kompatibilität ist außerdem die Absicherung der Schnittstelle ein wichtiger Punkt. REST-/OData-Verbindungen werden heute meist über OAuth2 abgesichert – ein Token-basiertes Verfahren, bei dem sich das Kundenportal einmalig authentifiziert und dann zeitlich begrenzte Zugriffstoken erhält, statt bei jeder Anfrage Zugangsdaten mitzuschicken. Klassische SOAP-Schnittstellen setzen häufig auf WS-Security oder feste Benutzerkonten mit Zertifikaten. Beide Verfahren sind sicher, wenn sie korrekt eingerichtet sind – wichtig ist, dass die Zugriffsrechte im Portal genauso granular abgebildet werden wie im ERP-System selbst, damit niemand über die Schnittstelle mehr sieht als über das ERP direkt.
Bei qibriX prüfen wir das bei jedem Projekt zuerst: Welche Schnittstellen existieren bereits im ERP-System, wie aktuell sind sie, welche Antwortzeiten braucht das Portal wirklich, und wie werden die Zugriffsrechte sauber abgebildet? Erst danach legen wir fest, ob REST, SOAP oder eine Kombination aus beiden die richtige Lösung für Ihr ERP Webportal ist – ohne unnötige Neuentwicklung dort, wo eine bestehende Schnittstelle bereits zuverlässig läuft. So bleibt die Anbindung wartbar, nachvollziehbar und passt zu dem, was Ihre IT-Abteilung ohnehin schon betreut.
Wir schauen uns Ihre bestehende SAP- oder caniasERP-Landschaft an und empfehlen den passenden Anbindungsweg.