SOAP (Simple Object Access Protocol) ist ein Nachrichtenprotokoll, mit dem Anwendungen strukturierte Daten über verschiedene Systeme, Plattformen und Programmiersprachen hinweg austauschen können. Jede Nachricht ist im XML-Format verfasst und folgt einer strengen, veröffentlichten Spezifikation. Aus diesem Grund ist SOAP nach wie vor das Rückgrat der Integration in den Bereichen Versicherung, Bankwesen, Versorgungswirtschaft, Telekommunikation und Gesundheitswesen – Branchen, in denen eine fehlerhaft formatierte Nachricht nicht nur einen Programmfehler darstellt, sondern ein Compliance-Problem ist.
Dieser Leitfaden erläutert, was eine SOAP-API ist, wie eine SOAP-Nachricht aufgebaut ist, welche Stärken SOAP hat, wo Kosten entstehen und wie Sie sich bei einer bestimmten Schnittstelle zwischen SOAP und REST entscheiden können. Wenn Sie eine moderne Anwendung an ein jahrzehntealtes Kernsystem anbinden, werden Sie dabei mit ziemlicher Sicherheit auf SOAP stoßen.
Was ist eine SOAP-API?
Eine SOAP-API ist eine Schnittstelle, die auf dem SOAP-Protokoll basiert. Sie ermöglicht es Anwendungen und Systemen, über ein Netzwerk miteinander zu kommunizieren, indem sie strukturierte XML-Nachrichten austauschen, und stellt Dienste und Funktionen jedem Client zur Verfügung, der diesen Vertrag lesen kann. Da das Format unabhängig von der Laufzeitumgebung definiert ist, kann ein Java-Dienst von einem .NET-Client genutzt werden, eine Mainframe-Transaktion kann von einer Webanwendung aus ausgelöst werden, und keine der beiden Seiten muss etwas über den Technologie-Stack der anderen wissen.
SOAP unterstützt zudem Remote Procedure Calls, was bedeutet, dass ein Client eine Funktion aufrufen kann, die sich in einem völlig anderen Adressraum befindet, und ein typisiertes Ergebnis zurückerhält. Diese Fähigkeit ist einer der Gründe, warum SOAP zum Standard in serviceorientierten Architekturen (SOA) und in verteilten Unternehmenslandschaften geworden ist, in denen Dutzende von Systemen eine gemeinsame, vorhersehbare Möglichkeit benötigen, sich gegenseitig aufzurufen.
Der Name ist ein historisches Relikt: SOAP stand ursprünglich für „Simple Object Access Protocol“, doch das Akronym wurde in SOAP 1.2 offiziell aufgegeben. Heute lautet die Bezeichnung einfach SOAP.
Aus welchen Komponenten besteht eine SOAP-Nachricht?
Jede SOAP-Nachricht ist ein XML-Dokument, wodurch die Übertragung strukturierter Daten plattform- und sprachunabhängig wird. Die Nachricht setzt sich aus drei Elementen zusammen – sowie einem Sonderfall.
SOAP Umschlag
Der SOAP-Umschlag ist die äußere Hülle. Er markiert den Anfang und das Ende der Nachricht und enthält alles andere. Wenn eine Nachricht keinen Umschlag hat, handelt es sich nicht um eine SOAP-Nachricht.
SOAP Kopfzeile
Der Header ist optional und enthält Metadaten statt Nutzdaten: Authentifizierungsdaten, Routing-Anweisungen, Transaktionskennungen, digitale Signaturen. Alles, was das empfangende System oder ein Zwischenknoten benötigt, um die Nachricht korrekt zu verarbeiten, gehört hierher und nicht in den Hauptteil.
SOAP Körper
Der Hauptteil enthält die eigentlichen Daten, die zwischen den Anwendungen ausgetauscht werden, einschließlich der Anweisungen für etwaige Remote Procedure Calls. Dies ist der Teil, der Ihrem Geschäftsablauf entspricht – der Versicherungsdatensatz, der Zählerstand, die Zahlungsanweisung.
SOAP Fehler
Der Hauptteil kann auch ein Fehlerelement enthalten. Wenn während der Verarbeitung ein Fehler auftritt, gibt die empfangende Anwendung anstelle des erwarteten Ergebnisses einen strukturierten Fehler zurück, der einen Code und eine für Menschen lesbare Begründung enthält. Die standardisierte Fehlerbehandlung ist eine der echten Stärken von SOAP: Ihre Integrationsschicht muss nicht allein anhand eines HTTP-Statuscodes erraten, was ein Fehler bedeutet.
Wie sieht ein typischer Nachrichtenablauf bei SOAP aus?
Eine SOAP-Nachricht wird zwischen einer Client- und einer Serveranwendung ausgetauscht. Es gibt immer einen Absender ( SOAP ) und einen Empfänger ( SOAP ), wobei der Empfänger die vom Absender übermittelten Daten interpretiert und validiert. Zwischen den beiden kann die Nachricht einen oder mehrere Zwischenknoten ( SOAP ) durchlaufen. Jeder Knoten muss auf die Nachricht reagieren – er kann sie verarbeiten, ergänzen oder einen Fehler auslösen.
Nachrichten werden in der Regel über HTTP übertragen, doch SOAP ist bewusst transportunabhängig. SMTP (Simple Mail Transfer Protocol) und JMS (Java Message Service) sind gleichermaßen geeignete Übertragungsprotokolle, was dann von Bedeutung ist, wenn Sie eine garantierte, asynchrone Zustellung anstelle einer synchronen Anfrage-Antwort-Kommunikation über das Internet benötigen.
SOAP und WSDL: der Vertrag, der dafür sorgt, dass es funktioniert
SOAP Webdienste werden in der Regel mithilfe von WSDL (Web Services Description Language) beschrieben. Eine WSDL-Datei ist eine maschinenlesbare Spezifikation dessen, was der Dienst bietet: welche Operationen es gibt, welche Eingaben die einzelnen Operationen erwarten, welche Ergebnisse sie zurückgeben und wo sie erreichbar sind.
Die praktische Folge davon ist, dass Entwicklungsteams die Schnittstelle nicht in einer Besprechung abstimmen müssen. Ein Client-Stub kann direkt aus der WSDL generiert werden, und wenn der Anbieter den Vertrag ändert, bricht der Build des Verbrauchers sofort ab, anstatt stillschweigend fehlerhafte Anfragen in die Produktion zu senden. In großen Organisationen mit getrennten Teams auf beiden Seiten einer Schnittstelle ist diese Formalität ein Vorteil und kein Mehraufwand.
Welche Vorteile bietet SOAP für Unternehmen?
Integrierte Sicherheit. WS-Security definiert Verschlüsselung und digitale Signaturen auf Nachrichtenebene und nicht nur auf Transportebene. Eine signierte SOAP-Nachricht bleibt auch nach dem Verlassen des TLS-Tunnels überprüfbar – selbst wenn sie einen Zwischenhost durchläuft, in eine Warteschlange gelangt und diese wieder verlässt. Für sensible Daten, die Organisationsgrenzen überschreiten, lässt sich diese End-to-End-Garantie nur schwer nachbilden.
Zuverlässiger Nachrichtenaustausch. WS-ReliableMessaging und damit verbundene Standards erkennen Übertragungsfehler und gewährleisten die Integrität der Nachrichten sowie die Zustellungssemantik. In geschäftskritischen Prozessen – etwa bei einer Zahlung, einer Vertragsänderung oder einem Netzumschaltbefehl – ist die Gewissheit, dass eine Nachricht genau einmal angekommen ist, die zusätzlichen Bytes wert.
Interoperabilität im Bereich Transport. Da SOAP auf dem TCP/IP-Stack aufbaut, anstatt sich an ein bestimmtes Protokoll zu binden, funktioniert es über HTTP/HTTPS, FTP, SMTP und Nachrichtenwarteschlangen. Es integriert Technologien nahtlos, unabhängig von Plattform, Betriebssystem oder Programmiersprache.
Komplexe Datenstrukturen. XML verarbeitet tief verschachtelte, stark typisierte Dateninhalte mit Schemavalidierung. Während ein Endpunkt nach dem Prinzip REST eine benutzerdefinierte Validierungslogik erfordern würde, übernimmt ein XSD diese Aufgabe, noch bevor Ihr Geschäftslogikcode überhaupt ausgeführt wird.
Ein formeller Vertrag. WSDL vereinfacht die Zusammenarbeit zwischen verschiedenen Entwicklungsteams und sorgt dafür, dass die Schnittstelle überprüfbar ist – was Aufsichtsbehörden in den Bereichen Finanzen, Versicherungen und Gesundheitswesen in der Regel zu schätzen wissen.
Ein internationaler Standard. SOAP ist eine W3C-Empfehlung. Gerade wegen seiner Stabilität und Beständigkeit über Jahrzehnte hinweg wird es nach wie vor in so vielen Kernsystemen verwendet.
Was sind die Herausforderungen bei der Nutzung von SOAP?
SOAP ist nicht überall die richtige Antwort, und es lohnt sich, ehrlich zu den Gründen dafür zu sein.
Ausführlichkeit und Komplexität. Durch die XML-Struktur sind die Nachrichten von SOAP deutlich umfangreicher als die von REST verwendeten JSON-Nutzdaten. Die Entwicklung, debugging sowie das bloße Lesen einer Nachricht dauern länger, und die Interoperabilität mit bestimmten Plattformen kann zusätzlichen Integrationsaufwand erfordern.
Netzwerk- und Verarbeitungsaufwand. Zusätzliche Sicherheits- und Header-Informationen führen zu größeren Nachrichten und längeren Verarbeitungszeiten als bei einem vergleichbaren REST-Aufruf. Bei einer stark frequentierten, latenzempfindlichen öffentlichen API ist dieser Unterschied messbar.
Geltungsbereich. „ SOAP “ definiert den Nachrichtenaustausch. Es handelt sich dabei nicht um eine vollständige Objektarchitektur, und es werden damit weder die Diensterkennung noch die Versionsstrategie oder das clientseitige Caching für Sie gelöst.
Verfügbarkeit von Entwicklern. Neue Dienste werden überwiegend mit REST entwickelt, sodass der Pool an Entwicklern, die sich mit WSDL, XSD und WS-* auskennen, immer kleiner wird. Dies stellt bei langlebigen SOAP-Systemlandschaften ein Personalrisiko dar, ist jedoch kein technischer Mangel.
Bei den meisten neuen Webdiensten geht der Trend zu schlankeren Formaten, wie sie beispielsweise von REST verwendet werden. Ob SOAP die richtige Wahl ist, hängt von Ihrer bestehenden Infrastruktur, Ihren Compliance-Anforderungen und den Ihnen zur Verfügung stehenden Ressourcen ab.
SOAP REST: Welches sollte man verwenden?
SOAP Sowohl REST als auch „Web Services“ sind Ansätze zur Implementierung von Webdiensten und zur Ermöglichung der Kommunikation zwischen verteilten Anwendungen. Sie unterscheiden sich hinsichtlich der Kommunikationsart, des Datenformats und der Art und Weise, wie sie den zugrunde liegenden Transport nutzen. SOAP ist ein Protokoll mit einer strengen Spezifikation; REST ist ein Architekturansatz, der auf bestehenden Webstandards aufbaut.
| Kriterium | SOAP | REST |
|---|---|---|
| Typ | Protokoll mit einer formalen Spezifikation | Architekturstil |
| Datenformat | Nur XML | JSON, XML, Klartext, Sonstiges |
| Verkehr | HTTP, SMTP, JMS, FTP | HTTP/HTTPS |
| Vertrag | WSDL, maschinenlesbar und verbindlich | OpenAPI, eher üblich als vorgeschrieben |
| Sicherheit | WS-Security, auf Nachrichtenebene | HTTPS, OAuth 2.0, Transportebene |
| Bundesland | Unterstützung für zustandsbehaftete Vorgänge | Von Grund auf zustandslos |
| Fehlerbehandlung | Standardisierter Fehler SOAP | HTTP-Statuscodes und benutzerdefinierte Nutzdaten |
| Nutzlastgröße | Größer – Umschlag und Kopfzeilen verursachen zusätzlichen Aufwand | Kleiner – leichtgewichtiges JSON |
| Am besten geeignet für | SOA, regulierte Branchen, veraltete Kernsysteme, garantierte Zustellung | Web- und mobile Anwendungen, Microservices, öffentliche APIs |
In der Praxis hängt die Wahl von den Anforderungen der jeweiligen Schnittstelle ab und nicht von einer unternehmensweiten Präferenz. REST eignet sich in der Regel besser für Webanwendungen und öffentliche APIs; SOAP bleibt die bessere Wahl für komplexe Kommunikationsarchitekturen wie die serviceorientierte Architektur sowie überall dort, wo ein Altsystem bereits eine WSDL bereitstellt. In den meisten Unternehmenslandschaften kommen letztendlich beide zum Einsatz – und genau dieses Problem soll eine Integrationsplattform lösen.
Die andere Seite dieses Vergleichs finden Sie in unserem Leitfaden zu „REST -APIs und RESTful-Webdiensten“.
Welche Branchen setzen nach wie vor auf SOAP?
SOAP wird branchenübergreifend in Bereichen eingesetzt, in denen regulierte, hochwertige Transaktionen vorherrschen. Versicherungsgesellschaften nutzen es für den Austausch von Policen und Schadensmeldungen, Banken für Zahlungs- und Kontoschnittstellen, Versorgungsunternehmen und Energieversorger für die Zählerablesung und die Kommunikation im Stromnetz, Telekommunikationsbetreiber für die Bereitstellung und Abrechnung sowie Organisationen im Gesundheitswesen für Patienten- und Abrechnungsdaten. In all diesen Bereichen lässt sich die installierte Basis von SOAP-Schnittstellen in Jahrzehnten und nicht in Jahren messen.
Die Zukunft von SOAP: Was können Unternehmen erwarten?
Die Entwicklung neuer APIs verläuft zunehmend in Richtung REST, doch SOAP hat in bestimmten Systemen und Anwendungen nach wie vor eine klare Daseinsberechtigung. Realistisch gesehen ist davon auszugehen, dass bestehende SOAP-Architekturen langfristig gewartet werden müssen, insbesondere wenn sie als Schnittstelle zu älteren Technologien dienen, die in absehbarer Zeit nicht ersetzt werden.
SOAP eröffnet zudem weiterhin neue Möglichkeiten. Durch die Bereitstellung von auf SOAP basierenden Diensten in der Cloud erhalten Unternehmen Zugriff auf zusätzliche Funktionen und Daten, und die Cloud-Infrastruktur ermöglicht ihnen eine flexible Skalierung der Ressourcen: Steigt die Nachfrage nach einem SOAP-Dienst, kann die Plattform zusätzliche Kapazitäten für den Lastausgleich bereitstellen. Das üblichere Muster ist jedoch eine Fassade – eine moderne REST- oder ereignisgesteuerte Schnittstelle vor einem stabilen SOAP-Kern, sodass neue Anwendungen niemals direkt mit WSDL kommunizieren müssen.
Anbindung von SOAP-Diensten an X4 BPMS
Die meisten Integrationsprojekte scheitern nicht am Protokoll. Sie scheitern an der Vielzahl der Protokolle. Ein einzelner Prozess muss möglicherweise Daten von einem Webdienst unter SOAP abrufen, an einen Endpunkt unter REST schreiben, eine Datei über SFTP herunterladen und ein Ereignis an eine Warteschlange senden – und jemand muss all das unter einen Hut bringen.
Die Low-Code-Plattform X4 BPMS wird mit mehr als 200 vorgefertigten Adaptern ausgeliefert, darunter Clients und Server für SOAP und REST , sodass für die Anbindung eines bestehenden Webdienstes kein benutzerdefinierter Code erforderlich ist. Der integrierte Enterprise Service Bus übernimmt das Routing, die Transformation und den Nachrichtenfluss zwischen den Systemen, und mithilfe modellierter BPMN 2.0-Prozesse können Sie die Abläufe zwischen den Systemen koordinieren: den Dienst SOAP aufrufen, das XML transformieren, es aus einem zweiten System anreichern und das Ergebnis an den Prozess weiterleiten, der es benötigt.
Das API-Management spielt hier eine wichtige Rolle, da es einzelne Schnittstellen in eine geregelte Funktion verwandelt. Eine zentrale Plattform macht Systeme und Daten für interne und externe Entwickler zugänglich, was die Entwicklung neuer digitaler Produkte und Dienstleistungen beschleunigt, Prozesse angesichts von Marktveränderungen agil hält und die Zusammenarbeit zwischen internen Teams und externen Partnern vereinfacht. Erfahren Sie mehr über nahtlose Integration oder über die Wahl zwischen ESB, Middleware und Microservices.
Befinden Sie sich gerade mitten in einer digitalen Transformation? Wir unterstützen Sie bei der Konzeption und Umsetzung – von Schulungen bis hin zu dedizierten Entwicklungsteams. Informieren Sie sich über unsere Beratungsleistungen oder erfahren Sie, wie die Automatisierung von Geschäftsprozessen in der Praxis funktioniert.
Als Chief Technology Officer treibt Wolfgang Wiesner seit Mai 2025 die technologische Weiterentwicklung von SoftProject voran. Sein Schwerpunkt liegt auf zukunftssicheren Architekturen, technologischer Exzellenz und der erfolgreichen Umsetzung innovativer IT-Lösungen.
Häufig gestellte Fragen
Was ist eine SOAP-API?
Eine SOAP-API ist eine Schnittstelle, die auf dem SOAP-Protokoll basiert. Sie ermöglicht es Anwendungen, strukturierte XML-Nachrichten über ein Netzwerk auszutauschen, sodass Dienste und Funktionen eines Systems von einem anderen System genutzt werden können, unabhängig von der Plattform oder der Programmiersprache.
Wofür steht SOAP?
SOAP stand ursprünglich für „Simple Object Access Protocol“. Mit der Version 1.2 von SOAP wurde das Akronym offiziell aufgegeben, sodass der Name nun für sich allein verwendet wird.
Was ist der Unterschied zwischen der SOAP-API und der REST-API?
SOAP ist ein Protokoll mit einer strengen Spezifikation, das ausschließlich XML verwendet und über verschiedene Transportprotokolle ausgeführt werden kann. REST ist ein Architekturansatz, der HTTP nutzt und in der Regel JSON-Daten austauscht. SOAP bietet Sicherheit auf Nachrichtenebene und einen formalen WSDL-Vertrag; REST ist schlanker, lässt sich schneller entwickeln und eignet sich besser für Web- und mobile Anwendungen.
Wird SOAP im Jahr 2026 noch verwendet?
Ja. Neue öffentliche APIs basieren fast immer auf REST, doch SOAP ist nach wie vor weit verbreitet in den Bereichen Versicherungen, Bankwesen, Versorgungsunternehmen, Telekommunikation und Gesundheitswesen, wo bestehende Kernsysteme SOAP -Schnittstellen bereitstellen und Sicherheit auf Nachrichtenebene sowie eine garantierte Zustellung erforderlich sind.
Was ist ein SOAP-Umschlag?
Der SOAP-Umschlag ist das äußerste XML-Element einer SOAP-Nachricht. Er definiert, wo die Nachricht beginnt und endet, und enthält den optionalen Header sowie den obligatorischen Body.
Können SOAP und REST parallel ausgeführt werden?
Ja, und in den meisten Unternehmensumgebungen ist dies auch der Fall. Eine Integrationsplattform wie X4 BPMS kann einen Webdienst vom Typ SOAP nutzen und dieselbe Geschäftsfunktion wie ein Endpunkt vom Typ REST bereitstellen, sodass neue Anwendungen niemals direkt mit WSDL arbeiten müssen.
