it-swarm.com.de

Vergleichen und kontrastieren Sie REST und SOAP Web Services?

Ich finde derzeit heraus, dass beide das Internetprotokoll (HTTP) verwenden, um Daten zwischen Verbraucher und Anbieter auszutauschen.

Der Unterschied ist:

  1. SOAP ist ein XML-basiertes Nachrichtenprotokoll, während REST ein Architekturstil ist
  2. SOAP verwendet WSDL für die Kommunikation zwischen Consumer und Provider, während REST nur XML oder JSON zum Senden und Empfangen von Daten verwendet
  3. SOAP ruft Dienste durch Aufrufen der RPC-Methode auf. REST ruft Dienste einfach über den URL-Pfad auf
  4. SOAP gibt keine von Menschen lesbaren Ergebnisse zurück, während REST das Ergebnis nur mit einfachem XML oder JSON lesbar ist
  5. SOAP ist nicht nur über HTTP verfügbar, sondern verwendet auch andere Protokolle wie SMTP, FTP usw. REST ist nur über HTTP verfügbar

Das ist alles, was ich als die Unterschiede zwischen ihnen kenne. Könnte jemand mich korrigieren und mehr hinzufügen.

74
Huppo

SOAP verwendet WSDL für die Kommunikation zwischen Consumer und Provider, wohingegen REST nur XML oder JSON zum Senden und Empfangen von Daten verwendet

WSDL definiert den Vertrag zwischen Client und Service und ist von Natur aus statisch. Im Falle von REST ist der Vertrag etwas kompliziert und wird durch HTTP, URI, Medienformate und das anwendungsspezifische Koordinierungsprotokoll definiert. Er ist im Gegensatz zu WSDL hoch dynamisch.

SOAP gibt keine von Menschen lesbaren Ergebnisse zurück, während REST das Ergebnis nur mit einfachem XML oder JSON lesbar ist

Das ist nicht wahr. Normales XML oder JSON sind überhaupt nicht REST-fähig. Keine von ihnen definiert irgendwelche Steuerelemente (dh Verknüpfungen und Verknüpfungsbeziehungen, Methodeninformationen, Codierungsinformationen usw.), die im Widerspruch zu REST soweit Nachrichten in sich geschlossen sein müssen und die Interaktion zwischen Agent/Kunde und Service.

Mit Links + Semantic Link Relations sollten Kunden in der Lage sein, den nächsten Interaktionsschritt zu bestimmen, diesen Links zu folgen und die Kommunikation mit dem Dienst fortzusetzen.

Es ist nicht erforderlich, dass Nachrichten für Menschen lesbar sind. Es ist möglich, ein kryptisches Format zu verwenden und absolut gültige REST) - Anwendungen zu erstellen. Es spielt keine Rolle, ob Nachrichten für Menschen lesbar sind oder nicht.

Daher sind einfaches XML (application/xml) oder JSON (application/json) keine ausreichenden Formate zum Erstellen von REST) - Anwendungen. Es ist immer sinnvoll, eine Teilmenge dieser generischen Medientypen zu verwenden, die eine starke semantische Bedeutung haben und bieten genügend Steuerungsinformationen (Links usw.), um die Interaktionen zwischen Client und Server zu koordinieren.

REST ist über nur HTTP

Nicht wahr, HTTP wird am häufigsten verwendet, und wenn wir über REST Webdienste sprechen, nehmen wir nur HTTP an. HTTP definiert die Schnittstelle mit seinen Methoden (GET, POST, PUT, DELETE, PATCH usw.) und verschiedenen Header, die einheitlich für die Interaktion mit Ressourcen verwendet werden können, können auch mit anderen Protokollen verwendet werden.

P.S. Sehr einfache, aber sehr interessante Erklärung von REST: http://www.looah.com/source/view/2284

54
ioseb

In der täglichen Praxis der Programmierung besteht der größte Unterschied darin, dass Sie mit SOAP mit statischen und fest definierten Datenaustauschformaten arbeiten, während Sie mit REST und JSON Datenaustausch arbeiten Die Formatierung ist im Vergleich dazu sehr locker. Mit SOAP können Sie beispielsweise überprüfen, ob die ausgetauschten Daten mit einem XSD-Schema übereinstimmen. Das XSD dient daher als "Vertrag" darüber, wie der Client und der Server verstehen sollen, wie die auszutauschenden Daten strukturiert sein müssen.

JSON-Daten werden in der Regel nicht in einem fest definierten Format weitergegeben (es sei denn, Sie verwenden ein Framework, das dies unterstützt. Beispiel: http : //msdn.Microsoft.com/en-us/library/jj870778.aspx oder Implementierung von json-schema).

In der Tat würden einige (viele/die meisten) argumentieren, dass die "dynamische" geheime Soße von JSON gegen die Philosophie/Kultur der Einschränkung durch Datenverträge verstößt ( Sollten JSON RESTful-Webdienste Datenverträge verwenden )

Leute, die es gewohnt sind, in dynamischen, lose geschriebenen Sprachen zu arbeiten, fühlen sich mit der Lockerheit von JSON wohler, während Entwickler von stark geschriebenen Sprachen XML bevorzugen.

http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide

4
MikeM

SOAP bringt sein eigenes Protokoll mit und konzentriert sich darauf, Teile der Anwendungslogik (nicht Daten) als Dienste bereitzustellen. SOAP macht Operationen verfügbar. SOAP konzentriert sich auf den Zugriff auf benannte Operationen und implementiert jeweils eine Geschäftslogik über verschiedene Schnittstellen.

Obwohl SOAP im Allgemeinen als "Web-Services" bezeichnet wird, ist dies eine falsche Bezeichnung. SOAP hat sehr wenig, wenn überhaupt etwas mit dem Web zu tun. REST stellt echte "Web-Services" bereit, die auf URIs und HTTP basieren.

Zur Veranschaulichung sind hier nur wenige Anrufe und deren geeignete Heimat mit Kommentaren.

getUser(User);

Dies ist eine Ruheoperation, wenn Sie auf eine Ressource (Daten) zugreifen.

switchCategory(User, OldCategory, NewCategory)

REST lässt viele verschiedene Datenformate zu, wobei SOAP nur XML zulässt. Dies scheint jedoch die Komplexität von REST zu erhöhen, da Sie mehrere Formate verarbeiten müssen Meiner Erfahrung nach hat es sich als sehr vorteilhaft erwiesen: JSON passt normalerweise besser zu Daten und analysiert sie viel schneller. REST ermöglicht eine bessere Unterstützung für Browser-Clients, da es JSON unterstützt.

0
Shiven