it-swarm.com.de

WSDL vs REST Vor-und Nachteile

Verbunden:

Warum sollte man REST anstelle von Web-Services verwenden?

Worauf muss ich bei der Entscheidung, ob ein Web-Service mithilfe von SOAP oder REST implementiert wird (womit ich HTTP/XML auf RESTful-Weise meine), und an was muss ich denken? Ich gehe davon aus, dass dies keine Einheitsgröße ist, also wie wähle ich die zu verwendende aus.

98
Howard May

Die folgenden Links enthalten nützliche Informationen zu WSDL vs REST, einschließlich Vor- und Nachteile

Ein paar wichtige Punkte sind das 

1) SOAP wurde für eine verteilte Computerumgebung entwickelt, in der REST für eine Punkt-zu-Punkt-Umgebung entwickelt wurde.

2) WADL kann verwendet werden, um die Schnittstelle für REST - Dienste zu definieren.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and-wadl

33
Howard May

Die beiden Protokolle haben in der realen Welt sehr unterschiedliche Verwendungen.

SOAP (mit WSDL) ist ein umfangreicher XML-Standard, der sich auf die Dokumentübergabe konzentriert. Der Vorteil dabei ist, dass Ihre Anfragen und Antworten sehr gut strukturiert sind und sogar eine DTD verwenden können. Der Nachteil ist, dass es XML ist und sehr ausführlich ist. Dies ist jedoch gut, wenn zwei Parteien einen strengen Vertrag benötigen (beispielsweise für die Kommunikation zwischen Banken). Mit SOAP können Sie beispielsweise Dokumente wie WS-Security überlagern. SOAP ist im Allgemeinen transportunabhängig, dh Sie müssen nicht unbedingt HTTP verwenden.

REST ist sehr leicht und verlässt sich bei seiner Arbeit auf den HTTP-Standard. Es ist großartig, einen nützlichen Web-Service schnell verfügbar zu machen. Wenn Sie keine strenge API-Definition benötigen, ist dies der richtige Weg. Die meisten Webdienste fallen in diese Kategorie. Sie können Ihre API so versionieren, dass Aktualisierungen der API sie nicht für Benutzer mit älteren Versionen brechen (sofern sie eine Version angeben). REST erfordert im Wesentlichen HTTP und ist formatunabhängig (dh Sie können XML, JSON, HTML oder was auch immer verwenden).

Im Allgemeinen verwende ich REST, da ich keine ausgefallenen WS- * -Funktionen benötige. SOAP ist jedoch gut, wenn Sie möchten, dass Computer Ihren Webservice mithilfe einer WSDL verstehen. REST Spezifikationen sind im Allgemeinen nur für Menschen lesbar.

107
Kekoa

In Bezug auf WSDL (was "SOAP" bedeutet) als "schwer". Schwer wie? Wenn das Toolset das ganze "schwere Heben" für Sie erledigt, warum ist es dann wichtig?

Ich musste noch nie eine komplizierte REST API verwenden. Wenn ich das tue, erwarte ich, dass ich mir eine WSDL wünsche, die meine Tools gerne in eine Reihe von Proxy-Klassen umwandeln, sodass ich nur scheinbar Methoden aufrufen kann. Stattdessen vermute ich, dass es zum Verwenden einer nicht trivialen REST-basierten API erforderlich sein wird, eine erhebliche Menge an "leichtem" Code von Hand zu schreiben.

Selbst wenn das alles erledigt ist, haben Sie immer noch eine für Menschen lesbare Dokumentation in Code übersetzt, mit dem Risiko, dass die Menschen sie falsch lesen. Da WSDL eine maschinenlesbare Beschreibung des Dienstes ist, ist es sehr viel schwieriger, "falsch zu lesen".


Nur eine Anmerkung: seit diesem Beitrag hatte ich habe die Gelegenheit, mit einem mäßig komplizierten REST -Dienst zu arbeiten. Ich wünschte mir in der Tat eine WSDL oder ähnliches, und ich musste tatsächlich viel Code von Hand schreiben. Tatsächlich wurde ein erheblicher Teil der Entwicklungszeit damit verbracht, die Code-Duplizierung des gesamten Codes zu entfernen, der verschiedene Service-Operationen "von Hand" aufgerufen hat.

19
John Saunders

Dies gehört wahrscheinlich wirklich als Kommentar in einige der obigen Posts, aber ich habe noch nicht den Repräsentanten, der das macht.

Ich finde es interessant, dass viele der häufig für SOAP und REST genannten Vor- und Nachteile (IMO) sehr wenig mit den tatsächlichen Werten oder Grenzen der beiden Technologien zu tun haben. Der wahrscheinlich am häufigsten genannte Vorteil von REST ist, dass es "leicht" ist oder dazu neigt, "besser lesbar" zu sein. Auf einer Ebene ist dies zweifellos der Fall, da REST eine niedrigere Eintrittsbarriere aufweist - es gibt weniger erforderliche Strukturen als SOAP (obwohl ich denjenigen zustimme, die gesagt haben, dass gute Werkzeuge hier im Wesentlichen die Antwort sind - Schade, dass ein Großteil der SOAP Werkzeuge ziemlich schrecklich ist.

Abgesehen von diesen anfänglichen Eintrittskosten ergibt sich der REST Eindruck meiner Meinung nach aus einer Kombination der Form der Anforderungs-URLs und der Komplexität der Daten, die von den meisten REST - Diensten ausgetauscht werden. REST fördert in der Regel einfachere, besser lesbare Anforderungs-URLs, und die Daten sind in der Regel auch besser verdaulich. Inwieweit sind diese jedoch REST inhärent und inwieweit sind sie lediglich zufällig. Die einfachere URL-Struktur ist ein direktes Ergebnis der Architektur - sie könnte jedoch auch auf SOAP -basierte Dienste angewendet werden. Die besser verdaulichen Daten sind eher auf das Fehlen einer definierten Struktur zurückzuführen. Das bedeutet, dass Sie Ihre Datenformate einfacher halten sollten, da sonst viel Arbeit anfällt. Die zusätzliche Struktur von SOAP, die von Vorteil sein sollte, ermöglicht tatsächlich ein schlampiges Design, und dieses schlampige Design wird dann als Dig gegen die Technologie verwendet.

Für den Austausch strukturierter Daten zwischen Computersystemen bin ich mir nicht sicher, ob REST von Natur aus besser ist als SOAP (oder umgekehrt). Sie sind einfach unterschiedlich. Ich denke, der Vergleich von REST vs SOAP mit dynamischer vs. statischer Typisierung ist gut. Wo dyanmische Sprachen zu Problemen neigen, ist die langfristige Wartung und Instandhaltung eines Systems (und auf lange Sicht spreche ich nicht ein oder zwei Jahre, ich spreche 5 oder 10). Es wird interessant sein zu sehen, ob REST mit der Zeit denselben Herausforderungen gegenübersteht. Ich neige zu der Annahme, dass dies der Fall sein wird, wenn ich ein verteiltes Informationsverarbeitungssystem aufbauen würde, das ich als Kommunikationsmechanismus SOAP heranziehe (auch aufgrund der Übertragungsprotokollschichtung und der Flexibilität, die es bietet, wie oben erwähnt wurde) ).

An anderen Stellen scheint jedoch REST angemessener zu sein. AJAX zwischen dem Client und seinem Server (unabhängig von der Nutzlast) ist ein wichtiges Beispiel. Ich mag die Langlebigkeit dieser Art von Verbindung nicht sonderlich, und Benutzerfreundlichkeit und Flexibilität sind ein absolutes Muss. Ebenso, wenn ich einen schnellen Zugriff auf einen externen Dienst benötigte und nicht dachte, dass mir die Wartbarkeit der Interaktion im Laufe der Zeit etwas ausmachen würde (wieder gehe ich davon aus, dass REST mich dies kosten wird) mehr, so oder so), dann könnte ich REST wählen, um schnell ein- und auszusteigen.

Auf jeden Fall sind sie beide brauchbare Technologien, und je nachdem, welche Kompromisse Sie für eine bestimmte Anwendung eingehen möchten, können sie Ihnen gute (oder schlechte) Dienste leisten.

15
sfitts

Für mich sollten wir vorsichtig sein, wenn wir den Word-Webdienst verwenden. Wir sollten immer angeben, ob wir von SOAP Webservice, REST Webservice oder anderen Arten von Webdiensten sprechen, weil wir hier über verschiedene Dinge sprechen und die Menschen dies nicht verstehen mehr, wenn wir alle Web-Services benannt haben.

Grundsätzlich SOAP Web Services sind seit Jahren sehr gut etabliert und folgen einer strengen Spezifikation, die beschreibt, wie mit ihnen zu kommunizieren ist, basierend auf der SOAP Spezifikation . Now REST Webservices sind etwas neuer und wirken im Wesentlichen einfacher, da sie kein Kommunikationsprotokoll verwenden. Grundsätzlich ist das, was Sie senden und empfangen, wenn Sie einen REST Web-Service verwenden, reines XML. Die Leute mögen es, weil sie die XML-Datei nach Belieben parsen können, ohne sich mit einem ausgefeilteren Kommunikationsprotokoll wie SOAP auseinandersetzen zu müssen.

Für mich REST Dienste sind fast so, als würden Sie ein Servlet anstelle eines SOAP Webdienstes erstellen. Das Servlet holt Daten ein und gibt Daten zurück. Das Format der Daten basiert auf XML. Wir können uns auch vorstellen, etwas anderes als xml zu verwenden, wenn wir wollen. Zum Beispiel könnten Tags anstelle von xml verwendet werden und das wäre nicht mehr REST = etwas anderes (Könnte in Bezug auf das Gewicht noch leichter sein, da xml von Natur aus nicht leicht ist). Würden wir das noch als Webservice bezeichnen? Ja, wir könnten, aber dies wird keinem aktuellen Standard folgen. Dies ist das Hauptproblem, wenn wir anfangen, alles als Web-Services zu bezeichnen, aber wir können es so machen, wie wir es wollen, dann verlieren wir auf der Interoperabilitätsseite der Dinge. Das heißt, das Format der Daten, die mit dem Webservice ausgetauscht werden, ist nicht mehr standardisiert. Dies setzt voraus, dass Server und Client sich auf das Format der Daten einigen, wohingegen mit SOAP bereits alles vordefiniert ist und Server und Client zusammenarbeiten können, ohne einander zu kennen, da sie dem gleichen Standard folgen.

Was Leute mit SOAP nicht mag, ist, dass sie es schwer haben, es zu verstehen und die Abfragen nicht manuell generieren können. Computer können dies sehr gut. Dies ist jedoch der Punkt, an dem wir uns darüber im Klaren sein müssen: Werden Web-Services-Abfragen und -Antworten direkt von den Endbenutzern verwendet, oder stimmen wir zu, dass Web-Services unter einer API liegen, die von Computersystemen aufgerufen wird, die auf normalisierten Systemen basieren Standards? 

5
Laize Laville

REST ist kein Protokoll; Es ist ein architektonischer Stil. Oder ein Paradigma, wenn Sie möchten. Das bedeutet, dass es viel loser ist als SOAP. Für grundlegende CRUD können Sie auf Standardprotokolle wie Atompub zurückgreifen. Bei den meisten Diensten stehen Ihnen jedoch mehr Befehle als nur diese zur Verfügung.

Als <Consumer> kann SOAP je nach Sprachunterstützung ein Segen oder ein Fluch sein. Da SOAP stark an ein streng typisiertes System angelehnt ist, funktioniert es am besten mit statisch typisierten Sprachen. Für eine dynamische Sprache kann es leicht knusprig und überflüssig werden. Darüber hinaus ist die Client-Library-Unterstützung außerhalb der Welt von Java und .NET nicht besonders gut

5
troelskn

SOAP: Es kann auch über SMTP transportiert werden, dh wir können den Dienst auch über das E-Mail-Textformat "Simple" aufrufen

Es ist ein zusätzliches Framework/eine Engine erforderlich, die sich in einem Web-Service-Consumer-Computer befinden muss, um die Nachricht SOAP in die jeweilige Objektstruktur in verschiedenen Sprachen zu konvertieren. 

REST: Jetzt unterstützt WSDL2.0 auch den REST - Webdienst

Wir können Sie verwenden, wenn Sie Ihren Service als leichtgewichtig gestalten möchten, z. B. Anrufe von mobilen Geräten wie Mobiltelefon, PDA usw. durchführen möchten.

3

für Unternehmenssysteme, in denen Ihr System auf Ihre Unternehmen beschränkt ist, ist die Verwendung von Seife einfacher und zweckmäßiger, da Sie die Kontrolle über Ihre Kunden haben. Es ist einfacher, da es eine Vielzahl von Tools gibt, die Klassen (Proxies) erstellen und so aussehen, als würden Sie Ihre regulären OOP ausführen, die Ihrer Java- oder .NET-Umgebung (in der die meisten Unternehmen verwenden) entspricht.

Ich würde REST für Internetanwendungen zum Anzeigen von Schnittstellen (wie Twitter-API) verwenden, da Clients Javascripts oder HTML oder andere verwenden können, bei denen die Eingabe nicht streng ist. REST liberaler zu sein, macht mehr Sinn.

Auch für Internetkunden (World Wide Web) ist es einfacher, Json oder XML, die aus einer Restschnittstelle stammen, zu parsen, als eine reine XML-Datei, die aus einer Seifenschnittstelle stammt. Es ist schwierig, Proxys auf Javascript zu verwenden, und Javascript unterstützt Objekte natürlich nicht. Wenn Sie REST mit Javascript verwenden, würden Sie normalerweise die Json-Zeichenfolge parsen und sind dann aus. Schnittstellen, die mit dem Internet verbunden sind, sind in der Regel sehr einfach (daher meist die einfache Analyse) und verlangt normalerweise keine Konsistenz, weshalb REST ausreichend ist. 

Ich glaube nicht, dass REST für Unternehmensanwendungen angemessen ist, da Transaktionen, Sicherheit, strikte Typisierung und Schemas eine sehr wichtige Rolle bei der Entwicklung von Unternehmensanwendungen spielen. Aus diesem Grund ist SOAP für sie besser geeignet.

Meine Schlussfolgerung ist, dass SOAP für Enterprise-Systeme gilt, REST für das Internet oder WWW. Sie können es austauschbar verwenden, haben aber möglicherweise Schwierigkeiten, das richtige Werkzeug für den Job nicht zu verwenden.

entschuldigung für mein schlechtes Englisch. 

3
monte

Zur Verteidigung von REST folgt es den Prinzipien von HTTP und der Adressierbarkeit, z. Leseoperationen verwenden GET, Aktualisierungsoperationen verwenden POST usw. Ich halte dies für einen weitaus saubereren Ansatz. Das Oreilly-Buch RESTful Web Services erklärt dies weitaus besser als ich. Wenn Sie es lesen, denke ich, würden Sie den REST -Ansatz vorziehen

2
Nick Allen

Die vorherigen Antworten enthalten viele Informationen, aber ich denke, es gibt einen philosophischen Unterschied, auf den noch nicht hingewiesen wurde. SOAP war die Antwort auf "Wie erstellen wir einen modernen, objektorientierten, plattform- und protokollunabhängigen Nachfolger von RPC?". REST entwickelte sich aus der Frage, "wie können wir die Erkenntnisse, die HTTP für das Web so erfolgreich gemacht haben, nutzen und für verteiltes Computing verwenden?"

Bei SOAP geht es darum, Ihnen Werkzeuge zur Verfügung zu stellen, mit denen die verteilte Programmierung wie ... Programmierung aussehen kann. REST versucht, einen Stil festzulegen, um verteilte Schnittstellen zu vereinfachen, sodass verteilte Ressourcen aufeinander verweisen können, wie verteilte HTML-Seiten aufeinander verweisen können. Eine Möglichkeit, dies zu tun, ist der Versuch, Operationen (meistens) auf "CRUD" für Ressourcen zu beschränken (Erstellen, Lesen, Aktualisieren, Löschen).

REST ist noch jung - obwohl es auf "von Menschen lesbare" Dienste ausgerichtet ist, schließt es keine Introspektionsdienste usw. oder die automatische Erstellung von Proxies aus. Diese wurden jedoch (wie ich schreibe) nicht standardisiert. SOAP gibt Ihnen diese Dinge, aber (IMHO) gibt Ihnen "nur" diese Dinge, wohingegen der von REST auferlegte Stil aufgrund seiner Einfachheit bereits die Verbreitung von Web-Services fördert. Ich würde selbst Neulingsdiensteanbietern empfehlen, REST zu wählen, es sei denn, es gibt bestimmte von SOAP bereitgestellte Funktionen, die sie verwenden müssen.

Meiner Meinung nach würde ich, wenn Sie eine "Greenfield" -API implementieren und nicht so viel über mögliche Kunden wissen, REST als den Stil wählen, der durch sie gefördert wird, dazu, Schnittstellen verständlicher und einfacher zu machen zu entwickeln. Wenn Sie sich mit Client und Server auskennen und es spezielle SOAP - Tools gibt, die beiden das Leben erleichtern, dann wäre ich mit REST nicht religiös.

1
shaunc

Das Toolset auf der Clientseite wäre eins. Und die Vertrautheit mit SOAP dient dem anderen. Heutzutage gehen immer mehr Dienste auf die RESTful-Route, und das Testen solcher Dienste kann mit einfachen cURL-Beispielen durchgeführt werden. Obwohl es nicht allzu schwierig ist, beide Methoden zu implementieren und die breiteste Nutzung durch Clients zu ermöglichen.

Wenn Sie sich für eines entscheiden müssen, würde ich REST vorschlagen, es ist einfacher. 

1
ahanson

Ich weiß, dass diese Diskussion eine alte ist, aber nachdem ich alle Antworten gelesen und kommentiert habe, glaube ich, dass jeder den wichtigsten Punkt in Bezug auf den Unterschied zwischen den beiden Systemen verpasst hat: SOAP verwendet komplexe Typen, um Ihnen nicht nur die Daten, aber validieren Sie sie und bewahren Sie sie in der strengen Typenbezeichnung auf, für die sie definiert wurde. Eine WSDL informiert Sie über das Datenformat und den Datentyp, ermöglicht das Hinzufügen von Regeln im Reg-Ex-Musterstil und definiert, wie oft ein Datenelement in einer Anforderung/Antwort zulässig sein muss und darf Ruhe dagegen hat keinen dieser Mechanismen.

SOAP ist komplex und umfangreich, da Sie komplexe, hierarchische Daten senden können. REST ist einfacher Text, wobei der Ursprung und der Endpunkt die Regeln sortieren.

SOAP ist geschäftsunabhängig, da alle Datenregeln in das Dokument eingebettet sind.

Der Unterschied zwischen SOAP und REST besteht darin, dass SOAP ein in sich geschlossenes, geschäftsorientiertes Schema ist. REST ist ein Textdokument.

0
CrazyMerlin

Sie können Ihre WSDL-spendenden WCF-Webkomponenten einfach auf andere Zwecke umstellen, indem Sie einfach Ihre Konfigurationseinstellungen ändern. Sie können über HTTP und dann Named Pipes, TCP, benutzerdefinierte Protokolle usw. navigieren, ohne Ihren Code ändern zu müssen. Ich glaube, dass WCF-Komponenten auch einfacher für Sicherheitsfunktionen, bidirektionale Anrufe, Transaktionen, Parallelität usw. eingerichtet werden können.

REST beschränkt sich weitgehend auf HTTP (was in vielen Fällen in Ordnung ist).

0
Tad Donaghe