SOAP (Simple Object Access Protocol)

Eine SOAP-Nachricht ist wie ein Brief mit Umschlag (Envelope).

<soap:Envelope>
  <soap:Header> (Security Tokens) </soap:Header>
  <soap:Body>
    <GetPrice>
      <Item>Apple</Item>
    </GetPrice>
  </soap:Body>
</soap:Envelope>

Niemand schreibt das von Hand. Tools (wie SoapUI oder IDEs) lesen die WSDL und bauen den Client-Code für dich.

1. WS-Security

Die Stärke von SOAP. Es hat eingebaute Standards für Verschlüsselung und Signatur auf Nachrichtenebene. Selbst wenn die Nachricht über ungesichertes HTTP geht (oder per Email!), bleibt sie sicher, weil der XML-Inhalt selbst verschlüsselt ist. REST verlässt sich meist nur auf HTTPS (Transport Layer).

2. ACID Transaktionen

SOAP unterstützt verteilte Transaktionen (WS-AtomicTransaction). "Buche Geld bei Bank A ab UND bei Bank B drauf. Wenn eines fehlschlägt, rolle BEIDES zurück." Mit REST extrem schwer zu bauen (Saga Pattern). Mit SOAP "out of the box" (wenn auch komplex).

3. Transportunabhängigkeit

REST braucht fast zwingend HTTP. SOAP kann über HTTP, SMTP (Email), JMS (Message Queue) oder TCP laufen. Dem Protokoll ist der Transport egal.

WSDL (The Contract First Approach)

Wo REST auf formlose Swagger/OpenAPI-Dokumentation vertraut (die oft asynchron zum Code verfällt), forciert SOAP echtes Contract First Design. Bevor ein Programmierer auch nur ein Byte Logik schreibt, wird die WSDL (Web Services Description Language) definiert. Diese massive XML-Datei beschreibt XSD-Datentypen, Namespaces, Binding-Ports und Endpunkte. Das Feature: Die WSDL ist streng typisiert. Wenn eine Java-App (Maven JAX-WS) oder ein C#-Client die WSDL importiert, generieren sie vollautomatisch 100% typsichere Service-Stubs (MyService.getMoney(int amount)). Ein Kompilierungsfehler tritt sofort auf, wenn die API-Struktur bricht. REST bot dies lange gar nicht (bis GraphQL und Protobuf aufkamen).

MTOM (Message Transmission Optimization Mechanism)

SOAP ist text-basiertes XML. Wenn du in SOAP ein PDF-Dokument (Image) übertragen willst, musst du es in Base64 encodieren. Das bläht die Dateigröße um 33% auf und verbrennt enorme CPU-Ressourcen beim Parsen (XML-Parser hassen Megabyte-lange Base64-Strings). Die Lösung ist MTOM. Wenn MTOM aktiviert ist, extrahiert der SOAP-Client das binäre File aus der XML-Baumstruktur, verpackt das pure XML und die reinen Binärdaten in einen Multipart/Related MIME-Envelope (ähnlich wie eine E-Mail mit Attachment) und sendet es. Auf der Gegenseite fügt der MTOM-Parser das Binary wieder nahtlos in das Document Object Model (DOM) ein. Massive Performance-Rettung für Enterprise Document-APIs.

WS-* Death Star (Die Überregulierung)

SOAP kollabierte unter seiner eigenen Bürokratie. Die "Web Services" Standards (liebevoll WS-* Death Star genannt) explodierten in den 2000ern. Neben WS-Security (SAML und X.509 Tokens) gab es WS-Addressing (für asynchrones Routing unabhängig vom HTTP-Transport), WS-ReliableMessaging (Message-Delivery-Garantien, selbst wenn die TCP-Verbindung reißt) und WS-AtomicTransaction (2-Phase-Commit verteilt über 5 Server). Diese Standards waren so gigantisch und akademisch, dass am Ende nur noch Großkonzerne wie IBM und Microsoft-Server miteinander sprechen konnten, weil alle anderen Open-Source-Parser die Tausenden Seiten Spezifikation nicht fehlerfrei implementieren konnten.