SOAP vs REST (Unterschiede)

Question

Ich habe Artikel über die Unterschiede zwischen SOAP und REST als Kommunikationsprotokoll für Webdienste gelesen, aber ich glaube, dass die größten Vorteile von REST gegenüber SOAP sind:

1. REST ist dynamischer, es ist nicht notwendig, UDDI (Universal Description, Discovery, and Integration) zu erstellen und zu aktualisieren.

2. REST ist nicht auf das XML-Format beschränkt. RESTful-Webdienste können Klartext/JSON/XML senden.

Aber SOAP ist standardisierter (z. B.: Sicherheit).

Also liege ich mit diesen Punkten richtig?

Answer 1

Leider gibt es viele Missverständnisse und falsche Vorstellungen über REST. Nicht nur deine Frage und die Antwort von @cmd spiegeln dies wider, sondern auch die meisten Fragen und Antworten zu diesem Thema auf Stack Overflow.

SOAP und REST können nicht direkt verglichen werden, da das erste ein Protokoll ist (oder zumindest versucht zu sein) und das zweite ein Architekturstil. Dies ist wahrscheinlich eine der Ursachen für Verwirrung, da die Leute dazu neigen, alles was keine SOAP ist, als REST zu bezeichnen.

Wenn man es etwas genauer betrachtet und versucht einen Vergleich anzustellen, ist der Hauptunterschied zwischen SOAP und REST der Grad der Kopplung zwischen Client- und Server-Implementierungen. Ein SOAP-Client funktioniert wie eine benutzerdefinierte Desktop-Anwendung, eng mit dem Server verbunden. Es gibt einen strikten Vertrag zwischen Client und Server, und es wird erwartet, dass alles zusammenbricht, wenn eine Seite etwas ändert. Du musst ständige Aktualisierungen nach jeder Änderung vornehmen, aber es ist einfacher festzustellen, ob der Vertrag eingehalten wird.

Ein REST-Client ist eher wie ein Browser. Es ist ein generischer Client, der weiß, wie man ein Protokoll und standardisierte Methoden verwendet, und eine Anwendung muss sich darin einfügen. Du verletzt nicht die Protokollstandards, indem du zusätzliche Methoden erstellst, sondern nutzt die standardmäßigen Methoden und erstellst die Aktionen mit ihnen in deinem Medientyp. Wenn es richtig gemacht wird, gibt es weniger Kopplung und Änderungen können eleganter gehandhabt werden. Ein Client soll einen REST-Service betreten, ohne etwas über die API zu wissen, außer über den Einstiegspunkt und den Medientyp. Im SOAP benötigt der Client bereits Kenntnisse über alles, was er verwenden wird, oder die Interaktion beginnt gar nicht. Außerdem kann ein REST-Client durch code-on-demand erweitert werden, der vom Server selbst bereitgestellt wird, das klassische Beispiel hierfür ist JavaScript-Code, der zur Steuerung der Interaktion mit einem anderen Dienst auf der Client-Seite verwendet wird.

Ich denke, dies sind die entscheidenden Punkte, um zu verstehen, worum es bei REST geht und wie es sich von SOAP unterscheidet:

• REST ist protokollunabhängig. Es ist nicht an HTTP gebunden. Ähnlich wie du einem FTP-Link auf einer Website folgen kannst, kann eine REST-Anwendung jedes Protokoll verwenden, für das es ein standardisiertes URI-Schema gibt.

• REST ist keine Zuordnung von CRUD zu HTTP-Methoden. Lies diese Antwort für eine ausführliche Erklärung dazu.

• REST ist so standardisiert wie die Teile, die du verwendest. Sicherheit und Authentifizierung in HTTP sind standardisiert, also ist das, was du verwendest, wenn du REST über HTTP machst.

• REST ist ohne Hypermedia und HATEOAS nicht REST. Das bedeutet, dass ein Client nur den Einstiegspunkt URI kennt und die Ressourcen Links zurückgeben sollen, denen der Client folgen soll. Diese schicken Dokumentationsgeneratoren, die URI-Muster für alles geben, was du in einer REST-API tun kannst, verfehlen komplett den Punkt. Sie dokumentieren nicht nur etwas, das dem Standard folgen soll, sondern wenn du das tust, koppelst du den Client an einen bestimmten Moment in der Entwicklung der API, und alle Änderungen an der API müssen dokumentiert und angewendet werden, oder sie wird nicht funktionieren.

• REST ist der architektonische Stil des Webs selbst. Wenn du Stack Overflow betrittst, weißt du, was ein Benutzer, eine Frage und eine Antwort sind, du kennst die Medientypen und die Website liefert dir die Links dazu. Eine REST-API muss dasselbe tun. Wenn wir das Web so gestaltet hätten, wie die Leute denken, dass REST gemacht werden sollte, anstatt eine Startseite mit Links zu Fragen und Antworten zu haben, hätten wir eine statische Dokumentation, die erklärt, dass um eine Frage anzusehen, man den URI stackoverflow.com/questions/ nehmen muss, die id mit der Question.id ersetzen und das in den Browser einfügen muss. Das ist Unsinn, aber das ist, was viele Leute denken, was REST ist.

Dieser letzte Punkt kann nicht genug betont werden. Wenn deine Clients URIs aus Vorlagen in der Dokumentation erstellen und keine Links in den Ressourcendarstellungen erhalten, das ist kein REST. Roy Fielding, der Autor von REST, hat dies in diesem Blogbeitrag deutlich gemacht: REST-APIs müssen durch Hypertext gesteuert sein.

Wenn du all dies berücksichtigst, wirst du feststellen, dass während REST nicht auf XML beschränkt sein muss, um es mit einem anderen Format richtig zu machen, musst du das Format deiner Links entwerfen und standardisieren. Hyperlinks sind standardmäßig in XML, aber nicht in JSON. Es gibt Entwurfsstandards für JSON, wie HAL.

Schließlich ist REST nicht für jeden geeignet, und ein Beweis dafür ist, wie die meisten Menschen ihre Probleme mit den HTTP-APIs, die sie fälschlicherweise REST nannten, sehr gut lösen und nie darüber hinausgehen. REST ist manchmal schwer umzusetzen, besonders am Anfang, aber es zahlt sich im Laufe der Zeit durch eine einfachere Weiterentwicklung auf der Serverseite und die Widerstandsfähigkeit des Clients gegenüber Änderungen aus. Wenn du etwas schnell und einfach erledigen musst, kümmere dich nicht darum, REST richtig umzusetzen. Das ist wahrscheinlich nicht das, wonach du suchst. Wenn du etwas brauchst, das über Jahre oder sogar Jahrzehnte online bleiben muss, dann ist REST das Richtige für dich.

Answer 2

REST vs SOAP ist nicht die richtige Frage.

REST ist im Gegensatz zu SOAP kein Protokoll.

REST ist ein architektonischer Stil und ein Design für netzbasierte Softwarearchitekturen.

REST Konzepte werden als Ressourcen bezeichnet. Eine Darstellung einer Ressource muss zustandslos sein. Es wird über einen Medientyp dargestellt. Einige Beispiele für Medientypen sind XML, JSON und RDF. Ressourcen werden von Komponenten manipuliert. Komponenten fordern und manipulieren Ressourcen über eine standardisierte einheitliche Schnittstelle an. Im Falle von HTTP besteht diese Schnittstelle aus standardisierten HTTP-Operationen wie z. B. GET, PUT, POST, DELETE.

Die Frage von @Abdulaziz zeigt, dass REST und HTTP oft in Verbindung verwendet werden. Dies liegt hauptsächlich an der Einfachheit von HTTP und seiner sehr natürlichen Zuordnung zu den RESTful-Prinzipien.

Grundlegende REST-Prinzipien

Kommunikation zwischen Client und Server

Client-Server-Architekturen haben eine sehr deutliche Trennung der Zuständigkeiten. Alle Anwendungen, die im RESTful-Stil erstellt werden, müssen auch im Prinzip Client-Server sein.

Zustandslos

Jede Client-Anfrage an den Server erfordert, dass ihr Zustand vollständig dargestellt wird. Der Server muss die Client-Anfrage vollständig verstehen können, ohne einen Serverkontext oder einen Server-Sitzungsstatus zu verwenden. Daraus folgt, dass alle Zustände beim Client aufbewahrt werden müssen.

Cachebar

Cache-Einschränkungen können verwendet werden, so dass Antwortdaten als cachebar oder nicht-cachebar markiert werden können. Jede als cachebar markierte Daten können als Antwort auf dieselbe nachfolgende Anfrage wiederverwendet werden.

Einheitliche Schnittstelle

Alle Komponenten müssen über eine einzige einheitliche Schnittstelle interagieren. Da alle Komponenteninteraktionen über diese Schnittstelle erfolgen, ist die Interaktion mit verschiedenen Diensten sehr einfach. Die Schnittstelle ist gleich! Das bedeutet auch, dass Implementierungsänderungen isoliert durchgeführt werden können. Solche Änderungen beeinflussen die grundlegende Komponenteninteraktion nicht, da die einheitliche Schnittstelle immer unverändert bleibt. Ein Nachteil ist, dass Sie an die Schnittstelle gebunden sind. Wenn eine Optimierung für einen bestimmten Dienst durch Ändern der Schnittstelle bereitgestellt werden könnte, haben Sie Pech, da REST dies verbietet. Andererseits ist REST jedoch für das Web optimiert, daher die unglaubliche Beliebtheit von REST über HTTP!

Die oben genannten Konzepte stellen die charakteristischen Merkmale von REST dar und unterscheiden die REST-Architektur von anderen Architekturen wie Webdiensten. Es ist nützlich zu beachten, dass ein REST-Dienst ein Webdienst ist, aber ein Webdienst nicht unbedingt ein REST-Dienst ist.

Sehen Sie sich diesen Blog Beitrag zu REST-Designprinzipien für weitere Details zu REST und den oben genannten Punkten an.

BEARBEITEN: Inhalt basierend auf Kommentaren aktualisieren

Answer 3

SOAP (Simple Object Access Protocol) und REST (Representation State Transfer) sind beide auf ihre eigene Weise schön. Also vergleiche ich sie nicht. Stattdessen versuche ich das Bild darzustellen, wann ich REST und wann SOAP bevorzuge.

Was ist Nutzlast?

Wenn Daten über das Internet gesendet werden, enthält jede übertragene Einheit sowohl Kopfzeileninformationen als auch die tatsächlichen Daten, die gesendet werden. Der Header identifiziert die Quelle und das Ziel des Pakets, während die tatsächlichen Daten als Nutzlast bezeichnet werden. Im Allgemeinen handelt es sich bei der Nutzlast um die Daten, die im Auftrag einer Anwendung übertragen werden und die vom Zielsystem empfangenen Daten.

Jetzt muss ich zum Beispiel ein Telegramm senden, und wir alle wissen, dass die Kosten des Telegramms von einigen Worten abhängen werden.

Sag mir also zwischen den unten genannten beiden Nachrichten, welche ist günstiger zu senden?

Arin

oder

"name": "Arin"

Ich weiß, deine Antwort wird die zweite sein, obwohl beide dasselbe Nachricht repräsentieren, ist die zweite hinsichtlich der Kosten günstiger.

Also versuche ich zu sagen, dass das Senden von Daten über das Netzwerk im JSON-Format billiger ist als das Senden im XML-Format bezüglich der Nutzlast.

Hier ist der erste Vorteil oder die Vorteile von REST gegenüber SOAP. SOAP unterstützt nur XML, aber REST unterstützt verschiedene Formate wie Text, JSON, XML usw. Und wir wissen bereits, dass wir uns besser positionieren, wenn wir Json verwenden, bezüglich der Nutzlast.

Jetzt unterstützt SOAP nur XML, aber es hat auch seine Vorteile.

Wirklich! Wie?

SOAP basiert auf XML in drei Weisen Umschlag – der definiert, was sich in der Nachricht befindet und wie sie verarbeitet werden soll.

Eine Reihe von Kodierungsregeln für Datentypen, und schließlich das Layout der Prozeduraufrufe und gesammelten Antworten.

Dieser Umschlag wird über einen Transport (HTTP/HTTPS) gesendet, und ein RPC (Remote Procedure Call) wird ausgeführt, und der Umschlag kehrt mit Informationen in einem XML-formatierten Dokument zurück.

Der wichtige Punkt ist, dass einer der Vorteile von SOAP die Verwendung des „generischen“ Transports ist, aber REST verwendet HTTP/HTTPS. SOAP kann fast jeden Transport verwenden, um die Anfrage zu senden, aber REST kann das nicht. Also hier haben wir einen Vorteil der Verwendung von SOAP.

Wie ich bereits im vorherigen Abschnitt erwähnt habe „REST verwendet HTTP/HTTPS“, gehen wir etwas tiefer auf diese Worte ein.

Wenn wir über REST über HTTP sprechen, werden alle Sicherheitsmaßnahmen angewendet, die HTTP übernommen hat, und dies wird als Transportsicherheit bezeichnet und sie sichert Nachrichten nur, solange sie innerhalb des Drahtes sind, aber sobald sie auf der anderen Seite angekommen sind, wissen Sie nicht, wie viele Stufen sie durchlaufen müssen, bevor sie den eigentlichen Punkt erreichen, an dem die Daten verarbeitet werden. Und natürlich könnten all diese Stufen etwas anderes als HTTP verwenden. Also Rest ist nicht komplett sicher, oder?

Aber SOAP unterstützt SSL genau wie REST zusätzlich unterstützt es auch die WS-Sicherheit, die einige unternehmensspezifische Sicherheitsfunktionen hinzufügt. WS-Sicherheit bietet Schutz von der Erstellung der Nachricht bis zu ihrer Verwendung. Für die Transportsicherheit können alle Schwachstellen, die wir finden, durch die Verwendung von WS-Sicherheit verhindert werden.

Abgesehen davon, da REST durch sein HTTP-Protokoll begrenzt ist, ist seine Transaktionsunterstützung weder ACID-konform noch kann sie eine Zwei-Phasen-Commit über verteilte transnationale Ressourcen bieten.

Aber SOAP hat umfassende Unterstützung sowohl für ACID-basiertes Transaktionsmanagement für kurzlebige Transaktionen als auch für Kompensationsbasiertes Transaktionsmanagement für lang laufende Transaktionen. Es unterstützt auch Zwei-Phasen-Commit über verteilte Ressourcen.

Ich ziehe keine Schlussfolgerungen, aber ich würde eine auf SOAP-basierte Webservice bevorzugen, wenn Sicherheit, Transaktion usw. die Hauptbedenken sind.

Hier ist "Das Java EE 6 Tutorial", wo sie sagten Ein RESTful-Design kann angemessen sein, wenn folgende Bedingungen erfüllt sind. Schau es dir an.

Ich hoffe, du hattest Spaß beim Lesen meiner Antwort.

Answer 4

SOAP or REST for Web Services?

REST(REpresentational State Transfer)
REpresentational State of an Object is Transferred is REST i.e. we don't send Object, we send state of Object. REST is an architectural style. It doesn’t define so many standards like SOAP. REST is for exposing Public APIs(i.e. Facebook API, Google Maps API) over the internet to handle CRUD operations on data. REST is focused on accessing named resources through a single consistent interface.

SOAP(Simple Object Access Protocol)
SOAP brings its own protocol and focuses on exposing pieces of application logic (not data) as services. SOAP exposes operations. SOAP is focused on accessing named operations, each operation implement some business logic. Though SOAP is commonly referred to as web services this is misnomer. SOAP has a very little if anything to do with the Web. REST provides true Web services based on URIs and HTTP.

Why REST?

• Since REST uses standard HTTP it is much simpler in just about ever way.
• REST is easier to implement, requires less bandwidth and resources.
• REST permits many different data formats where as SOAP only permits XML.
• REST allows better support for browser clients due to its support for JSON.
• REST has better performance and scalability. REST reads can be cached, SOAP based reads cannot be cached.
• If security is not a major concern and we have limited resources. Or we want to create an API that will be easily used by other developers publicly then we should go with REST.
• If we need Stateless CRUD operations then go with REST.
• REST is commonly used in social media, web chat, mobile services and Public APIs like Google Maps.
• RESTful service return various MediaTypes for the same resource, depending on the request header parameter "Accept" as application/xml or application/json for POST and /user/1234.json or GET /user/1234.xml for GET.
• REST services are meant to be called by the client-side application and not the end user directly.
• ST in REST comes from State Transfer. You transfer the state around instead of having the server store it, this makes REST services scalable.

Why SOAP?

• SOAP is not very easy to implement and requires more bandwidth and resources.
• SOAP message request is processed slower as compared to REST and it does not use web caching mechanism.
• WS-Security: While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features.
• WS-AtomicTransaction: Need ACID Transactions over a service, you’re going to need SOAP.
• WS-ReliableMessaging: If your application needs Asynchronous processing and a guaranteed level of reliability and security. Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying.
• If the security is a major concern and the resources are not limited then we should use SOAP web services. Like if we are creating a web service for payment gateways, financial and telecommunication related work then we should go with SOAP as here high security is needed.

source1
source2

Answer 5

Meiner Meinung nach kann man SOAP und REST nicht vergleichen, da es sich um zwei unterschiedliche Dinge handelt.

SOAP ist ein Protokoll und REST ist ein Software-Architekturmuster. Im Internet herrscht viel Verwirrung über SOAP vs REST.

SOAP definiert ein auf XML basierendes Nachrichtenformat, das von webdienstfähigen Anwendungen genutzt wird, um miteinander über das Internet zu kommunizieren. Dafür benötigen die Anwendungen Vorwissen über den Nachrichtenvertrag, Datentypen, usw..

REST repräsentiert den Zustand (als Ressourcen) eines Servers über eine URL. Es ist zustandslos und Clients sollten kein Vorwissen darüber haben, wie sie mit dem Server interagieren können, abgesehen von dem Verständnis von Hypermedia.