SOAP erklärt: Aufbau, Vorteile, Nachteile, Standards und moderne Wrapper

SOAP (Simple Object Access Protocol) ist ein standardisiertes Protokoll für den Austausch strukturierter Nachrichten zwischen verteilten Systemen. SOAP setzt typischerweise auf XML als Nachrichtenformat und wird häufig über HTTP/HTTPS transportiert, ist aber grundsätzlich transportneutral. Während moderne Schnittstellen oft als REST- oder GraphQL-APIs umgesetzt werden, bleibt SOAP in vielen Enterprise- und Legacy-Umgebungen relevant – vor allem dort, wo Verlässlichkeit, Sicherheit und klare Verträge entscheidend sind.

Was ist SOAP?

SOAP ist kein Framework und auch kein Architekturstil wie REST, sondern ein Protokoll. Es definiert präzise Regeln dafür, wie Nachrichten aufgebaut sind, wie sie übertragen werden und wie Fehler zu behandeln sind. SOAP wird häufig in klassischen Unternehmensumgebungen eingesetzt, in denen Interoperabilität zwischen unterschiedlichen Technologien (z. B. Java, .NET, SAP) und eine langfristig stabile Schnittstelle wichtig sind.

SOAP in einem Satz

SOAP standardisiert, wie Systeme strukturierte XML-Nachrichten austauschen – inklusive optionaler Enterprise-Erweiterungen für Security, Zuverlässigkeit und Transaktionen.

Aufbau einer SOAP-Nachricht

Eine SOAP-Nachricht folgt einer festen Struktur. Die wichtigsten Bestandteile sind:

Envelope: Der „Umschlag“, der eine Nachricht als SOAP-Nachricht kennzeichnet.
Header (optional): Metadaten, z. B. Security-Informationen, Signaturen, Tokens, Routing, Transaktions-IDs.
Body: Enthält die eigentlichen Nutzdaten (Request/Response).
Fault (optional): Standardisierte Fehlerstruktur, falls etwas schiefgeht.

Envelope, Header, Body, Fault – kurz erklärt

Der Header ist besonders wichtig, wenn Anforderungen wie Signaturen, Verschlüsselung oder zuverlässige Zustellung über Enterprise-Standards abgebildet werden. Der Body enthält die Operation (Methodenaufruf) und deren Parameter. Im Fehlerfall liefert SOAP einen Fault, der Fehlercode, Fehlermeldung und Details enthalten kann.

WSDL: Der Vertrag eines SOAP-Services

SOAP-Services werden häufig über eine WSDL (Web Services Description Language) beschrieben. Die WSDL dient als formale Service-Beschreibung und definiert:

welche Operationen (Methoden) verfügbar sind
welche Datenstrukturen (Typen) gesendet und empfangen werden
welche Endpunkte existieren
welche Bindings und Transportprotokolle genutzt werden

Vorteil: Clients können aus der WSDL häufig automatisch generiert werden (Code-Generation).
Nachteil: Strikte Verträge reduzieren Flexibilität bei schnellen Änderungen.

Operationen, Methoden und Kommunikationsstil

SOAP basiert auf Operationen, die in XML beschrieben werden. Oft entspricht das einem „Remote Procedure Call“-Stil (RPC) oder einem dokumentenorientierten Stil (Document/Literal). Im Gegensatz zu REST ist SOAP nicht an die Semantik von HTTP-Methoden wie GET, POST, PUT gebunden. In der Praxis werden SOAP-Requests jedoch meist per HTTP POST übertragen – die eigentliche Logik steckt in der SOAP-Operation im XML-Body.

Beispiele für typische Operationen:

CreateShipment
GetStatus
UpdateOrder
CancelRequest

Standards und Regeln: WS-*

Ein großer Teil der Stärke von SOAP liegt in den optionalen Erweiterungsstandards, oft unter dem Schlagwort WS-* zusammengefasst. Häufig verwendete Bausteine sind:

WS-Security: Signaturen, Verschlüsselung, Tokens (Message-Level-Security)
WS-ReliableMessaging: Zuverlässige Zustellung (Wiederholungen, Reihenfolge)
WS-AtomicTransaction: Transaktionsunterstützung
WS-Addressing: Adressierung und Routing-Informationen
WS-Policy: Richtlinien, z. B. Security-Anforderungen oder Service-Regeln

Diese Standards machen SOAP besonders geeignet für Enterprise-Prozesse – erhöhen aber auch die Komplexität erheblich.

Vorteile von SOAP

Strikte Standardisierung: klare Regeln für Nachrichtenaufbau und Fehlerbehandlung.
Starker Vertrag (WSDL): definierte Typen und Operationen, ideal für große Organisationen.
Hohe Security-Fähigkeiten: WS-Security erlaubt Signaturen und Verschlüsselung auf Nachrichtenebene.
Zuverlässigkeit und Transaktionen: Standards für garantierte Zustellung und Transaktionssicherheit.
Transportneutralität: SOAP ist nicht ausschließlich an HTTP gebunden.
Langfristige Stabilität: SOAP-Schnittstellen bleiben oft über Jahre stabil.

Nachteile von SOAP

Hoher Overhead: XML ist ausführlich, Payloads sind größer als JSON.
Komplexität: WS-* und strikte Spezifikationen erhöhen Implementierungs- und Debugging-Aufwand.
Performance: Parsing und Message-Handling sind oft schwergewichtiger als bei REST/JSON.
Frontend-unfreundlich: Für Browser/Mobile weniger angenehm als JSON-basierte APIs.
Tooling abhängig vom Stack: In manchen Umgebungen ist SOAP sehr komfortabel, in anderen sperrig.

Wer verwendet SOAP?

SOAP wird vor allem dort eingesetzt, wo Verlässlichkeit, Sicherheit und formale Verträge im Vordergrund stehen. Typische Einsatzfelder sind:

Banken und Zahlungsverkehr
Versicherungen
Behörden und öffentliche Verwaltung
Logistik und Versanddienstleister
ERP-/Enterprise-Systeme (inkl. SAP-Umfelder)
Legacy-Systeme mit langfristig stabilen Schnittstellen

SOAP vs. REST vs. GraphQL (Kurzvergleich)

Merkmal	SOAP	REST	GraphQL
Art	Protokoll	Architekturstil	Query Language
Format	XML	meist JSON	JSON
Vertrag	WSDL	optional (OpenAPI)	Schema
Security	sehr stark (WS-*)	meist TLS + App-Logik	meist TLS + App-Logik
Flexibilität	niedriger	hoch	sehr hoch
Typische Nutzung	Enterprise/Legacy	Web APIs	Datengesteuerte Apps

Libraries und Packages

Java

JAX-WS
Apache CXF
Spring Web Services

.NET

WCF (Windows Communication Foundation)
System.ServiceModel

Node.js

soap (npm)
strong-soap (npm)

PHP

SoapClient (Core Extension)
Laminas SOAP

Wrapper und moderne Integration

Da SOAP in modernen Frontend- und Mobile-Stacks oft unhandlich ist, wird es häufig über Wrapper „modernisiert“. Das häufigste Muster ist ein SOAP->REST-Wrapper:

Intern kommuniziert der Wrapper mit dem SOAP-Service.
Extern bietet er eine REST/JSON-Schnittstelle an.
Clients (Web/Mobile/Third-Party) sprechen nur noch JSON.

Vorteile eines SOAP->REST-Wrappers

Einfachere Client-Integration (JSON statt XML)
Bessere Developer Experience (Swagger/OpenAPI möglich)
Gekapselte Komplexität (WS-* bleibt intern)
Zentrales Error-Handling und Logging
Gezielte Performance-Optimierung (Caching, Mapping, Retry-Strategien)

In der Praxis wird SOAP dadurch oft „unsichtbar“: Der Service bleibt stabil, während moderne Clients eine zeitgemäße Schnittstelle nutzen können.

Wann ist SOAP sinnvoll?

SOAP ist sinnvoll, wenn:

hohe Security-Anforderungen bestehen (Signaturen, Verschlüsselung auf Nachrichtenebene)
zuverlässige Zustellung und Transaktionen wichtig sind
langfristige, stabile Verträge benötigt werden
Enterprise- und Legacy-Systeme integriert werden müssen

SOAP ist weniger geeignet, wenn:

schnelle Iteration und flexible Datenformate wichtig sind
Frontend- oder Mobile-Clients direkt auf die API zugreifen
geringe Payload-Größe und niedrige Latenz im Vordergrund stehen

Fazit

SOAP ist ein robustes, standardisiertes Protokoll, das in vielen Enterprise-Umgebungen weiterhin eine wichtige Rolle spielt. Es punktet durch klare Verträge, starke Security-Optionen und zuverlässige Kommunikation – erkauft sich diese Stärken jedoch mit höherer Komplexität und mehr Overhead. In modernen Systemlandschaften wird SOAP häufig durch Wrapper-Architekturen ergänzt, sodass Clients eine zeitgemäße REST/JSON-Schnittstelle nutzen können, während SOAP im Hintergrund stabil bleibt.