REST oder SOAP in einer Cloud-nativen Umgebung

Cloud-basierte API-Datenmodelle haben nicht nur das Cloud-Erlebnis verbessert, sondern auch Entwicklern und Administratoren die Möglichkeit geboten, Workloads mithilfe dieser APIs in die Cloud zu integrieren. Für die meisten Unternehmen ermöglichen APIs den Informationsaustausch zwischen verschiedenen lokalen und Cloud-basierten Anwendungen. Sie spielen auch eine wichtige Rolle, um Plattform-Workloads nahtloser zu integrieren. Da die Cloud-Akzeptanz weiter zunimmt, besteht eine größere Nachfrage nach Integrationspunkten zwischen Anwendungen innerhalb und außerhalb der Cloud-Umgebung. Der Anstieg der Multicloud-Strategie und die Notwendigkeit einer Verbesserung der Cloud-übergreifenden Funktionen haben die Abhängigkeit von der Cloud-API-Umgebung erhöht. Aber welcher Ansatz ist besser und welche Unterstützung erhalten Sie in Ihrer Cloud-Umgebung?

Seife auf den Punkt gebracht

SOAP (kurz für Simple Object Access Protocol), der ältere Ansatz, wurde branchenweit unterstützt und reichte von Produktunternehmen wie IBM und Microsoft bis hin zu Service-Implementierern. Es kam auch mit einem umfassenden, aber komplexen Satz von Standards. Das Microsoft-Team, das SOAP entwickelt hat, hat es äußerst flexibel gemacht - um über private Netzwerke, über das Internet und E-Mails kommunizieren zu können. Es wurde auch von mehreren Standards unterstützt. Die ursprüngliche Version von SOAP war Teil einer Spezifikation, die auch UDDI (Universal Description, Discovery and Integration) und WSDL (Web Services Description Language) enthielt.

SOAP stellt im Wesentlichen den Umschlag zum Senden der Webdienstnachrichten bereit. Die Architektur selbst soll die Leistung verschiedener Vorgänge zwischen Softwareprogrammen unterstützen. Die Kommunikation zwischen Programmen erfolgt normalerweise über XML-basierte Anforderungen und HTTP-basierte Antworten. HTTP wird meistens als Kommunikationsprotokoll verwendet, es können jedoch auch andere Protokolle verwendet werden.

Eine SOAP - Nachricht enthält einige obligatorische Teile wie ENVELOPE, HEADER, BODY, und FAULT. Das  ENVELOPEObjekt definiert den Beginn und das Ende der XML-Nachrichtenanforderung, HEADERenthält alle vom Server zu verarbeitenden Headerelemente und BODYenthält das verbleibende XML-Objekt, aus dem die Anforderung besteht. FAULTObjekt wird jede Fehlerbehandlung verwendet.

SICH AUSRUHEN

REST (Representational State Transfer) wird normalerweise als Architekturstil und nicht als Protokoll bezeichnet, das zum Erstellen von Webdiensten verwendet wird. Die REST-Architektur ermöglicht die Kommunikation zwischen zwei Softwareprogrammen, wobei ein Programm Ressourcen von dem anderen anfordern und bearbeiten kann. REST Anfrage für Ressourcen auf Zielprogramm den Zugriff verwendet HTTP Verben: GET, POST, PUT, und DELETE. Diese Anforderungen können ein Datenformat einschließlich XML, HTML und JSON verwenden. JSON wird am meisten bevorzugt, da es am kompatibelsten und benutzerfreundlichsten ist. Die meisten REST-APIs basieren auf URIs (Uniform Resource Identifier) ​​und sind spezifisch für das HTTP-Protokoll. 

REST ist entwicklerfreundlich, da es aufgrund seines einfacheren Stils einfacher zu implementieren und zu verwenden ist als SOAP. REST ist weniger ausführlich und es wird weniger Datenvolumen gesendet, wenn zwischen zwei Endpunkten kommuniziert wird.

Warum SOAP oder REST?

Während SOAP wie die Verwendung eines Umschlags ist, der viele Verarbeitungsinformationen enthält, kann REST als Postkarte betrachtet werden, die einen URI als Zieladresse hat, leichtgewichtig ist und zwischengespeichert werden kann. REST ist datengesteuert und wird primär verwendet, um auf eine Ressource (URI) für bestimmte Daten zuzugreifen. SOAP ist ein funktionsgesteuertes Protokoll. REST bietet Flexibilität bei der Auswahl des Datenformats (Nur-Text, HTML, XML oder JSON), während SOAP nur XML verwendet.

SOAP eignet sich gut für Anwendungen, bei denen Sie ein höheres Maß an Sicherheit benötigen. SOAP bietet Sicherheitsfunktionen auf Unternehmensebene, die von WS-Security unterstützt werden, sowie SSL-Unterstützung. Wenn Sie eine Mobile-Banking-Lösung entwickeln möchten, sind SOAP-APIs wahrscheinlich die erste Überlegung für Sicherheitsanforderungen. SOAP bietet auch eine Wiederholungslogik für garantierten Erfolg und zuverlässige Kommunikation. REST verwendet HTTP und kann Kommunikationsfehler nur durch erneutes Versuchen beheben. Die Wiederholungslogik ist jedoch nicht in REST integriert. SOAP bietet eine integrierte Wiederholungslogik.

Was ändert sich in einer Cloud-nativen Umgebung?

Aus Entwicklersicht ändert sich nichts wirklich an der Wahl zwischen REST oder SOAP, aber das Entwerfen Ihres Dienstes in einer Cloud-nativen Umgebung bringt die Plattformperspektive in Betracht. Die Verfügbarkeit und Antwortzeit von Diensten spielt eine entscheidende Rolle beim Entwurf von Unternehmensdiensten und Cloud-nativen Anwendungen. Unter Sicherheitsgesichtspunkten wird das WS-Security-Protokoll (Web Service Security), das End-to-End-Sicherheit auf Nachrichtenebene mithilfe von SOAP-Nachrichten bietet, im Cloud-Computing häufig angewendet, um die Sicherheit der meisten Cloud-Computing-bezogenen Webdienste zu schützen. WS-Security verwendet jedoch SAOP-Header-Elemente, um sicherheitsrelevante Informationen zu übertragen. Eine SOAP-Nachricht hat ein XML-Format und ist normalerweise viel größer als die eigentliche Nachricht in einem Binärformat. Dies erhöht die Zeit und die Verarbeitung für die Kommunikation und Verarbeitung der Daten.Dies kann ein Diskussionsargument für die Wahl von REST gegenüber SOAP sein, es gibt jedoch eine Verschiebung von SOAP zu REST, unabhängig von der Plattform, auf der Ihre Anwendung ausgeführt wird.

Ende 2016 fügte Microsoft Azure der Azure-API-Verwaltung SOAP-Passthrough-Unterstützung hinzu, mit der Entwickler einen Proxy für ihre SOAP-APIs erstellen können, genauso wie sie einen Proxy für REST / HTTP-APIs erstellen. Mithilfe der SOAP-Passthrough-Unterstützung können Sie WSDL-Dokumente importieren und einen neuen API-Proxy erstellen. Der Prozess überprüft alle SOAP-Aktionen im Dokument und erstellt diese effektiv in API-Endpunkten. In einer zukünftigen Version wird möglicherweise eine Funktion angezeigt, die zum Erstellen eines REST-Frontends mithilfe eines SOAP-Backends angefordert wird.

In der AWS-Welt sind die meisten AWS-APIs nur über REST zugänglich und unterstützen SOAP nur eingeschränkt. EC2-Ressourcen sind über REST oder Query API verfügbar, während die SOAP-API für EC2 seit Ende 2015 veraltet ist. Dienste wie Amazon S3 und RDS unterstützen auch REST, während SOAP nur über HTTPS unterstützt wird. SOAP für HTTP ist veraltet. Amazon SQS unterstützt SOAP nicht mehr. Während REST anscheinend AWS-APIs anführt, lässt sich das Amazon API Gateway in das AWS-Ökosystem integrieren und bietet Unterstützung beim Erstellen, Verwalten und Bereitstellen einer RESTful-API, um Back-End-HTTP / HTTPS-Endpunkte, AWS Lambda-Funktionen und / oder andere AWS-Services verfügbar zu machen. API Gateway hilft auch beim Aufrufen verfügbarer API-Methoden über die Front-End-HTTP-Endpunkte.

Immer mehr Unterstützung tendiert zu RESTful-APIs. Seine Einfachheit mit verbartigen Operationen macht es entwicklerfreundlich. Es ist mit den meisten Formaten kompatibel und einfach zu bedienen. Es gibt auch keinen Sonnenuntergang für SOAP, aber REST wird definitiv in der Entwicklergemeinde beliebt sein.