/
Basis für SOA / REST oder SOAP?

Basis für SOA / REST oder SOAP?

Überblick

REST und SOAP sind zwei verschiedene Ansätze für die Online-Datenübertragung. Beide definieren, wie APIs, mit denen Daten zwischen Webanwendungen übertragen werden können, erstellt werden. REST (Representational State Transfer) umfasst eine Reihe von Softwarearchitektur-Prinzipien. SOAP (Simple Object Access Protocol) ist ein offizielles Protokoll, das vom World Wide Web Consortium (W3C) verwaltet wird. Der Hauptunterschied besteht darin, dass SOAP ein Protokoll ist, und REST nicht. In der Regel verwendet eine API je nach Use Case und Präferenzen des Entwicklers entweder REST oder SOAP.

 

REST: Representational State Transfer

REST umfasst eine Reihe von Softwarearchitektur-Prinzipien, die auf die Anforderungen schlanker Webservices und mobiler Anwendungen zugeschnitten sind. Da es sich um Richtlinien oder Empfehlungen handelt, bleibt die Implementierung letztlich den Entwicklern überlassen.

Wenn eine Datenanforderung an eine REST-API gesendet wird, erfolgt dies in der Regel über HTTP (Hypertext Transfer Protocol). Für REST entwickelte APIs (RESTful APIs oder RESTful Webservices) können je nach Anforderung Nachrichten in verschiedenen Formaten ausgeben: HTML, XML, Plain Text oder JSON. JSON (JavaScript Object Notation) wird als Nachrichtenformat bevorzugt, da es (trotz des Namens) von jeder Programmiersprache gelesen werden kann, für Menschen und Maschinen lesbar und kompakt ist. Daher sind RESTful APIs flexibler und einfacher einzurichten.

Eine Anwendung wird als RESTful bezeichnet, wenn sie den folgenden sechs Architekturrichtlinien entspricht. Eine RESTful Anwendung braucht:

  1. Eine Client-Server-Architektur, die aus Clients, Servern und Ressourcen besteht.

  2. Eine zustandslose Client-Server-Kommunikation, d. h. auf dem Server werden zwischen den Anforderungen keine Client-Inhalte gespeichert. Statt dessen werden Informationen zum Session-Status beim Client gespeichert.

  3. Cachingfähige Daten, um die Notwendigkeit einiger Client/Server-Interaktionen zu eliminieren.

  4. Eine einheitliche Schnittstelle zwischen Komponenten, um Informationen in standardisierter, statt anwendungsspezifischer Form zu übertragen. Roy Fielding, der Urheber von REST, beschreibt dies als „das zentrale Feature, das den REST-Architekturstil von anderen netzwerkbasierten Stilen unterscheidet".

  5. Ein Mehrschichtsystem, bei dem Client/Server-Interaktionen auf hierarchische Schichten erweitert werden.

  6. Code-on-Demand, mit dem Server die Funktionalität eines Clients durch die Übertragung von ausführbarem Code erweitern können. (Dabei wird die Sichtbarkeit verringert. Diese Richtlinie ist daher optional.)

SOAP: Simple Object Access Protocol

SOAP ist ein Standardprotokoll, das zunächst entwickelt wurde, damit Anwendungen, die mit verschiedenen Sprachen und auf verschiedenen Plattformen erstellt wurden, miteinander kommunizieren konnten. Da es sich um ein Protokoll handelt, umfasst es integrierte Regeln, die Komplexität und Overhead erhöhen, was zu längeren Seitenladezeiten führen kann. Diese Standards bieten jedoch integrierte Compliance, die es für Unternehmensszenarien attraktiv macht. Zu den integrierten Compliance-Standards gehören Sicherheit, Atomizität, Konsistenz, Isolation und Dauerhaftigkeit (ACID), eine Reihe von Eigenschaften zur Gewährleistung zuverlässiger Datenbanktransaktionen.

Zu den üblichen Webservice-Spezifikationen gehören:

  • WS-Security (Web Services Security): Standardisiert, wie Nachrichten durch eindeutige Kennungen, sogenannte Token, gesichert und übertragen werden.

  • WS-ReliableMessaging: Standardisiert die Fehlerbehandlung zwischen Nachrichten, die über eine unzuverlässige IT-Infrastruktur übertragen werden.

  • WS-Addressing (Web Services Addressing): Paketiert Routing-Informationen als Metadaten in SOAP-Headern, statt diese Informationen tiefer im Netzwerk zu verwalten.

  • WSDL (Web Services Description Language): Beschreibt, was ein Webservice tut und wo dieser Service beginnt und endet.

Wenn eine Datenanforderung an eine SOAP-API gesendet wird, kann sie über eines der Protokolle der Anwendungsschicht verarbeitet werden: HTTP (für Webbrowser), SMTP (für E-Mail), TCP und andere. Sobald eine Anforderung jedoch empfangen wird, müssen SOAP-Nachrichten als XML-Dokumente zurückgegeben werden – einer Markup-Sprache, die sowohl für Menschen als auch für Maschinen lesbar ist. Eine abgeschlossene Anfrage an eine SOAP-API kann nicht in einem Browser zwischengespeichert werden. Daher kann später auch nicht mehr auf die Anfrage zugegriffen werden, ohne sie erneut an die API zu senden.

SOAP oder REST?

Viele Altsysteme verwenden möglicherweise noch SOAP. REST wurde später eingeführt und gilt in webbasierten Szenarien häufig als die schnellere Alternative. REST besteht aus einer Reihe von Richtlinien für eine flexible Implementierung. SOAP ist ein Protokoll mit spezifischen Anforderungen wie XML-Messaging.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, sind aber aufwändiger zu erstellen. Darüber hinaus folgen auch viele öffentlich zugängliche APIs, wie die Google Maps-API, den REST-Richtlinien.

Related content

Was ist eine REST API?
Was ist eine REST API?
More like this
Was ist SOA (Service-Oriented Architecture)?
Was ist SOA (Service-Oriented Architecture)?
More like this
Standardsoftware vs Individualsoftware (Integrierte operative Systeme)
Standardsoftware vs Individualsoftware (Integrierte operative Systeme)
More like this
Grundlagen Vorgehensmodelle
Grundlagen Vorgehensmodelle
More like this
3-Schichten-Architektur von Datenbanksystemen
3-Schichten-Architektur von Datenbanksystemen
More like this
Kurzanwendungsfall: Standardsoftware vs. Individualentwicklung
Kurzanwendungsfall: Standardsoftware vs. Individualentwicklung
More like this