Frage SOAP vs REST (Unterschiede)


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

  1. REST ist dynamischer und erfordert kein Erstellen und Aktualisieren von UDDI.

  2. REST ist nicht auf das XML-Format beschränkt. REST-Web-Services können senden Klartext, JSON und auch XML.

Aber SOAP ist standardisierter (Ex; Sicherheit).

Also, bin ich in diesen Punkten richtig?


987
2017-11-09 23:11


Ursprung


Antworten:


Leider gibt es viele Fehlinformationen und Missverständnisse rund um REST. Nicht nur deine Frage und die Antwort von @cmd spiegeln diese, aber die meisten Fragen und Antworten zum Thema auf Stack Overflow.

SOAP und REST können nicht direkt verglichen werden, da das erste ein Protokoll ist (oder es zumindest versucht) und das zweite ein Architekturstil ist. Dies ist wahrscheinlich eine der Quellen der Verwirrung, da Leute dazu neigen, REST jede HTTP-API aufzurufen, die nicht SOAP ist.

Der Unterschied zwischen SOAP und REST ist der Grad der Kopplung zwischen Client- und Serverimplementierungen. Ein SOAP-Client funktioniert wie eine benutzerdefinierte Desktop-Anwendung, die eng mit dem Server verbunden ist. Es gibt einen starren Vertrag zwischen Client und Server, und es wird erwartet, dass alles bricht, wenn eine Seite irgendetwas ändert. Nach jeder Änderung müssen Sie ständig aktualisiert werden. Es ist jedoch einfacher festzustellen, ob der Vertrag befolgt wird.

Ein REST-Client ähnelt eher einem Browser. Es ist ein generischer Client, der weiß, wie man ein Protokoll und standardisierte Methoden verwendet, und eine Anwendung muss in diese passen. Sie verstoßen nicht gegen die Protokollstandards, indem Sie zusätzliche Methoden erstellen, Sie nutzen die Standardmethoden und erstellen die Aktionen mit diesen auf Ihrem Medientyp. Wenn es richtig gemacht wird, gibt es weniger Kopplung, und Änderungen können eleganter behandelt werden. Ein Client sollte einen REST-Service ohne Kenntnis der API eingeben, mit Ausnahme des Einstiegspunkts und des Medientyps. In SOAP benötigt der Client Vorwissen über alles, was er verwendet, oder er beginnt nicht einmal mit der Interaktion. Darüber hinaus kann ein REST-Client durch Code-on-Demand erweitert werden, der vom Server selbst bereitgestellt wird. Das klassische Beispiel ist ein JavaScript-Code, der die Interaktion mit einem anderen Dienst auf der Clientseite steuert.

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 gekoppelt. So wie Sie einem FTP-Link auf einer Website folgen können, kann eine REST-Anwendung jedes Protokoll verwenden, für das ein standardisiertes URI-Schema existiert.

  • REST ist keine Zuordnung von CRUD zu HTTP-Methoden. Lesen Dies Antwort für eine detaillierte Erklärung dazu.

  • REST ist so standardisiert wie die Teile, die Sie verwenden. Sicherheit und Authentifizierung in HTTP sind standardisiert, also verwenden Sie REST über HTTP.

  • REST ist nicht REST ohne Hypermedia und Hateonen. Dies bedeutet, dass ein Client nur den Einstiegspunkt-URI kennt und die Ressourcen Links zurückgeben sollen, denen der Client folgen soll. Jene phantastischen Dokumentationsgeneratoren, die URI-Muster für alles geben, was Sie in einer REST-API tun können, verpassen diesen Punkt völlig. Sie dokumentieren nicht nur etwas, das dem Standard folgen soll, aber wenn Sie das tun, binden Sie den Client an einen bestimmten Moment in der Entwicklung der API, und alle Änderungen an der API müssen dokumentiert und angewendet werden. oder es wird brechen.

  • REST ist der architektonische Stil des Webs selbst. Wenn Sie Stack Overflow eingeben, wissen Sie, was ein Benutzer, eine Frage und eine Antwort sind, Sie kennen die Medientypen, und die Website bietet Ihnen die Links zu ihnen. Eine REST-API muss das Gleiche tun. Wenn wir das Web so gestalten, wie es die Leute denken, sollte REST durchgeführt werden, anstatt eine Homepage mit Links zu Fragen und Antworten zu haben, haben wir eine statische Dokumentation, die erklärt, dass Sie die URI nehmen müssen, um eine Frage zu sehen stackoverflow.com/questions/<id>, ersetze die ID mit der Question.id und füge sie in deinen Browser ein. Das ist Unsinn, aber viele Leute denken, dass REST ist.

Dieser letzte Punkt kann nicht genug betont werden. Wenn Ihre Clients URIs aus Vorlagen in der Dokumentation erstellen und keine Links in den Ressourcendarstellungen erhalten, handelt es sich nicht um REST. Roy Fielding, der Autor von REST, machte in diesem Blogbeitrag klar: REST-APIs müssen hypertextgesteuert sein.

In Anbetracht dessen werden Sie feststellen, dass REST zwar nicht auf XML beschränkt ist, Sie jedoch für jedes andere Format ein Format für Ihre Links entwerfen und standardisieren müssen. Hyperlinks sind in XML Standard, nicht jedoch in JSON. Es gibt Entwurfsstandards für JSON, wie HAL.

Schließlich ist REST nicht jedermanns Sache, und ein Beweis dafür ist, dass die meisten Leute ihre Probleme sehr gut mit den HTTP-APIs lösen, die sie fälschlicherweise REST genannt haben, und niemals darüber hinausgehen. REST ist manchmal schwierig, besonders am Anfang, aber es zahlt sich im Laufe der Zeit mit einer einfacheren Entwicklung auf der Serverseite und der Widerstandsfähigkeit des Clients gegenüber Änderungen aus. Wenn Sie etwas schnell und einfach erledigen möchten, machen Sie sich keine Sorgen um REST. Es ist wahrscheinlich nicht das, wonach du suchst. Wenn Sie etwas brauchen, das für Jahre oder sogar Jahrzehnte online bleiben soll, dann ist REST für Sie da.


1461
2017-11-10 00:45



REST vs SOAP ist nicht die richtige Frage zu stellen.

REST, nicht wie SOAP ist nicht ein Protokoll.

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

REST Konzepte werden als Ressourcen bezeichnet. Eine Repräsentation einer Ressource muss zustandslos sein. Es wird über einen Medientyp dargestellt. Einige Beispiele für Medientypen umfassen XML, JSON, und RDF. Ressourcen werden durch Komponenten manipuliert. Komponenten fordern und manipulieren Ressourcen über eine einheitliche Standardschnittstelle. Im Fall von HTTP besteht diese Schnittstelle aus Standard-HTTP-Ops, z. GET, PUT, POST, DELETE.

@ Abdulaziz Frage beleuchtet die Tatsache, dass REST und HTTP werden oft im Tandem verwendet. Dies liegt hauptsächlich an der Einfachheit von HTTP und seiner sehr natürlichen Zuordnung zu REST-Prinzipien.

Grundlegende REST-Prinzipien

Client-Server-Kommunikation

Client-Server-Architekturen haben eine sehr deutliche Trennung von Bedenken. Alle im RESTful-Stil erstellten Anwendungen müssen grundsätzlich auch Client-Server sein.

Staatenlos

Jede Clientanforderung an den Server erfordert, dass ihr Status vollständig dargestellt wird. Der Server muss die Clientanforderung vollständig verstehen können, ohne Serverkontext oder Serversitzungsstatus zu verwenden. Daraus folgt, dass der gesamte Zustand auf dem Client gehalten werden muss.

Zwischenspeicherbar

Cache-Beschränkungen können verwendet werden, wodurch ermöglicht wird, dass Antwortdaten als zwischenspeicherbar oder nicht-zwischenspeicherbar markiert werden. Alle Daten, die als cachefähig gekennzeichnet sind, können als Antwort auf dieselbe nachfolgende Anforderung wiederverwendet werden.

Einheitliche Schnittstelle

Alle Komponenten müssen über eine einzige einheitliche Schnittstelle interagieren. Da die Interaktion aller Komponenten über diese Schnittstelle erfolgt, ist die Interaktion mit verschiedenen Diensten sehr einfach. Die Schnittstelle ist die gleiche! Dies bedeutet auch, dass Implementierungsänderungen isoliert durchgeführt werden können. Solche Änderungen beeinflussen die Wechselwirkung zwischen fundamentalen Komponenten nicht, da die einheitliche Schnittstelle immer unverändert bleibt. Ein Nachteil ist, dass Sie mit der Schnittstelle stecken bleiben. Wenn eine Optimierung für einen bestimmten Dienst durch Ändern der Schnittstelle bereitgestellt werden kann, haben Sie kein Glück, da REST dies verbietet. Auf der positiven Seite ist REST jedoch für das Web optimiert, was die unglaubliche Popularität von REST über HTTP bedeutet!

Die obigen Konzepte stellen definierende Merkmale von REST dar und unterscheiden die REST-Architektur von anderen Architekturen wie Web-Services. Es ist hilfreich zu beachten, dass ein REST-Service ein Web-Service ist, aber ein Web-Service nicht unbedingt ein REST-Service ist.

Siehe dieses Blog Post auf REST Designprinzipien für mehr Details auf SICH AUSRUHEN und die oben genannten Kugeln.

BEARBEITEN: Inhalt basierend auf Kommentaren aktualisieren


245
2017-11-09 23:19



Seife (Einfaches Objekt Zugriffsprotokoll) und Ruhe (Repräsentation Staat Übertragung) Beide sind wunderschön in ihrer Art. Also vergleiche ich sie nicht. Stattdessen versuche ich das Bild darzustellen, wenn ich REST und SOAP bevorzuge.

Was ist Nutzlast? 

Wenn Daten über das Internet gesendet werden, enthält jede gesendete Einheit sowohl Kopfinformationen als auch die tatsächlich gesendeten Daten. Der Header identifiziert die Quelle und das Ziel des Pakets, während die tatsächlichen Daten als Nutzlast bezeichnet werden. Im Allgemeinen sind die Nutzdaten die Daten, die im Namen einer Anwendung übertragen werden, und die Daten, die vom Zielsystem empfangen werden.

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

Also erzähle mir unter diesen beiden Nachrichten, welche man günstiger versenden kann?

<name>Arin</name>

oder

"name": "Arin"

Ich weiß, dass deine Antwort die zweite sein wird, obwohl beide, die gleiche Nachricht darstellend, eine zweite ist, die hinsichtlich der Kosten billiger ist.

Also versuche ich das zu sagen, Das Senden von Daten über das Netzwerk im JSON-Format ist billiger als das Senden im XML-Format in Bezug auf Nutzdaten.

Hier sind die ersten Vorteile von REST over SOAP. SOAP unterstützt nur XML, aber REST unterstützt verschiedene Formate wie Text, JSON, XML usw. Und wir wissen bereits, dass wir mit Json definitiv besser in Sachen Payload sind.

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

Ja wirklich! Wie?

SOAP basiert auf XML auf drei Arten Umschlag - definiert, was in der Nachricht enthalten ist und wie sie verarbeitet wird.

Eine Reihe von Codierungsregeln für Datentypen und schließlich das Layout der gesammelten Prozedurenaufrufe und Antworten.

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

Der wichtige Punkt ist, dass Einer der Vorteile von SOAP ist die Verwendung der "Generischer" Transport aber REST verwendet HTTP / HTTPS. SOAP kann fast jeden Transport verwenden, um die Anforderung zu senden, REST jedoch nicht. Also, hier haben wir einen Vorteil der Verwendung von SOAP.

Wie ich bereits im obigen Absatz erwähnt habe "REST verwendet HTTP / HTTPS"Geh also ein bisschen tiefer in diese Worte.

Wenn wir über REST über HTTP sprechen, werden alle angewendeten Sicherheitsmaßnahmen HTTP vererbt, und dies ist bekannt als Sicherheit auf Transportebene und es sichert Nachrichten nur während Es ist in dem Draht Aber sobald Sie es auf der anderen Seite abgeliefert haben, wissen Sie nicht, wie viele Stufen es durchlaufen wird, bevor Sie den wirklichen Punkt erreichen, an dem die Daten verarbeitet werden. Und natürlich könnten alle diese Stufen etwas anderes als HTTP verwenden.Also Ruhe ist nicht ganz sicher, oder?

Aber SOAP unterstützt SSL genau wie REST zusätzlich Es unterstützt auch WS-Sicherheit Das fügt einige Sicherheitsmerkmale für Unternehmen hinzu. WS-Security bietet Schutz vor der Erschaffung der Botschaft zu ihrem Konsum. Also für die Sicherheit auf Transportebene, welche Lücke wir auch finden, die mit WS-Security verhindert werden kann.

Abgesehen davon, als REST ist durch das HTTP-Protokoll eingeschränkt Daher ist die Transaktionsunterstützung weder ACID-konform noch kann sie eine zweistufige Festschreibung über verteilte transnationale Ressourcen hinweg ermöglichen.

Aber SOAP hat umfassende Unterstützung für beide ACID-basierte Transaktionsverwaltung für kurzlebige Transaktionen und kompensationsbasierte Transaktionsverwaltung für lang laufende Transaktionen. Es unterstützt auch zweiphasiges Commit über verteilte Ressourcen.

Ich ziehe keine Schlussfolgerung, aber ich werde SOAP-basierten Web-Service bevorzugen, während Sicherheit, Transaktion usw. die Hauptanliegen sind.

Hier ist das "Java EE 6 Tutorial", wo sie gesagt haben Ein RESTful-Design kann angebracht sein, wenn die folgenden Bedingungen erfüllt sind. Guck mal.

Ich hoffe, es hat Ihnen Spaß gemacht, meine Antwort zu lesen.


189
2018-06-14 19:48



SICH AUSRUHEN(REpräsentativ State TÜbertragung)
REST ist ein architektonischer Stil. Es definiert nicht so viele Standards wie SOAP. REST dient dazu, öffentliche APIs (d. H. Facebook API, Google Maps API) über das Internet verfügbar zu machen, um CRUD-Vorgänge an Daten zu handhaben. REST konzentriert sich auf den Zugriff auf benannte Ressourcen über eine einzige konsistente Schnittstelle.

SEIFE(Simplementieren OGegenstand EINZugang PRotocol)
SOAP bringt ein eigenes Protokoll mit und konzentriert sich darauf, Teile der Anwendungslogik (nicht Daten) als Dienste offenzulegen. SOAP macht Operationen verfügbar. SOAP konzentriert sich auf den Zugriff auf benannte Operationen, wobei jede Operation eine gewisse Geschäftslogik implementiert. Obwohl SOAP allgemein als bezeichnet wird Internetdienste Das ist irreführend. SOAP hat sehr wenig mit dem Web zu tun. REST bietet True Internetdienste basierend auf URIs und HTTP.

Warum RUHE? 

  • Da REST Standard-HTTP verwendet, ist es in jedem Fall viel einfacher.
  • REST ist einfacher zu implementieren, benötigt weniger Bandbreite und Ressourcen.
  • REST erlaubt viele verschiedene Datenformate, wobei SOAP nur XML zulässt.
  • REST ermöglicht aufgrund seiner Unterstützung für JSON eine bessere Unterstützung für Browser-Clients.
  • REST bietet eine bessere Leistung und Skalierbarkeit. REST-Lesevorgänge können zwischengespeichert werden, SOAP-basierte Lesevorgänge können nicht zwischengespeichert werden.
  • Wenn Sicherheit keine große Rolle spielt und wir nur begrenzte Ressourcen zur Verfügung haben. Oder wir möchten eine API erstellen, die von anderen Entwicklern öffentlich verwendet werden kann. Dann sollten wir mit REST fortfahren.
  • Wenn wir stateless CRUD-Operationen benötigen, dann gehen Sie mit REST.
  • REST wird häufig in sozialen Medien, Web-Chat, mobilen Diensten und öffentlichen APIs wie Google Maps verwendet.
  • RESTful-Service gibt verschiedene MediaTypes für dieselbe Ressource zurück, abhängig vom Anforderungsheaderparameter "Accept" als application/xml oder application/json für POST und /user/1234.json oder GET /user/1234.xml für GET.
  • REST-Dienste sollen von der clientseitigen Anwendung und nicht vom Endbenutzer direkt aufgerufen werden.
  • ST in REST kommt von State TÜbertragung. Sie übertragen den Status, anstatt ihn vom Server speichern zu lassen. Dadurch werden REST-Services skalierbar.

Warum SOAP? 

  • SOAP ist nicht einfach zu implementieren und erfordert mehr Bandbreite und Ressourcen.
  • Die SOAP-Nachrichtenanforderung wird im Vergleich zu REST langsamer verarbeitet und verwendet keinen Web-Caching-Mechanismus.
  • WS-Sicherheit: Während SOAP SSL (genau wie REST) ​​unterstützt, unterstützt es auch WS-Security, die einige Sicherheitsfunktionen des Unternehmens hinzufügt.
  • WS-AtomTransaktion: Benötigen Sie ACID-Transaktionen über einen Service, benötigen Sie SOAP.
  • WS-ReliableMessaging: Wenn Ihre Anwendung eine asynchrone Verarbeitung und ein garantiertes Maß an Zuverlässigkeit und Sicherheit benötigt. Rest verfügt nicht über ein Standardnachrichtensystem und erwartet von Clients, dass sie Kommunikationsfehler beheben, indem sie es erneut versuchen.
  • Wenn die Sicherheit ein großes Problem darstellt und die Ressourcen nicht begrenzt sind, sollten wir SOAP-Webdienste verwenden. Wie wenn wir einen Web-Service für Zahlungs-Gateways, finanzielle und telekommunikationsbezogene Arbeit erstellen, dann sollten wir SOAP verwenden, da hier hohe Sicherheit benötigt wird.

enter image description here

Quelle1
Quelle2


81
2017-12-08 23:38



Andere Antworten haben umfangreiche punktuelle Unterschiede aufgezeigt und ausführlich erläutert. Also würde ich dich von diesen Antworten abhalten und dich fragen, ob du immer noch verwirrt bist. Wenn ja, dann magst du vielleicht einen Blick auf diese einfache Analogie werfen. enter image description here


60
2018-06-23 05:19



Die Entscheidung zwischen den beiden wird Ihre erste Wahl bei der Gestaltung eines Web-Service sein, so dass es wichtig ist, die Vor- und Nachteile der beiden zu verstehen. Es ist auch wichtig, in der manchmal hitzigen Debatte zwischen den beiden Philosophien die Realität von der Rhetorik zu trennen.

REST-Grundlagen

  • Alles in REST wird als Ressource betrachtet.
  • Jede Ressource wird durch einen URI identifiziert.
  • Verwendet einheitliche Schnittstellen. Ressourcen werden mit POST-, GET-, PUT-, DELETE-Operationen behandelt, die Create-, Read-, Update- und Delete-Operationen (CRUD) ähneln.
  • Sei staatenlos. Jede Anfrage ist eine unabhängige Anfrage. Jede Anfrage vom Client zum Server muss alle Informationen enthalten, die zum Verständnis der Anfrage notwendig sind.
  • Die Kommunikation erfolgt über Repräsentationen. Zum Beispiel XML, JSON RESTful Web Services. Ein RESTful-Web-Service basiert auf HTTP-Methoden und dem Konzept von REST. Ein RESTful-Webdienst definiert normalerweise den Basis-URI für die Dienste. die unterstützten MIME-Typen (XML, Text, JSON, benutzerdefiniert, ...) und die Menge der Operationen (POST, GET, PUT, DELETE), die unterstützt werden.

SOAP-Grundlagen

  • WSDL definiert den Vertrag zwischen Client und Service und ist von Natur aus statisch.
  • SOAP erstellt ein XML-basiertes Protokoll zusätzlich zu HTTP oder manchmal TCP / IP.
  • SOAP beschreibt Funktionen und Datentypen.
  • SOAP ist ein Nachfolger von XML-RPC und ist sehr ähnlich, beschreibt jedoch einen Standardweg zur Kommunikation.
  • Mehrere Programmiersprachen bieten native Unterstützung für SOAP, Sie geben ihm normalerweise eine Web-Service-URL, und Sie können seine Web-Service-Funktionen aufrufen, ohne dass dafür ein spezifischer Code erforderlich ist.
  • Binäre Daten, die gesendet werden, müssen zuerst in einem Format wie dem Base64-kodierten Format codiert werden.
  • Hat mehrere Protokolle und Technologien dazu: WSDL, XSD, SOAP, WS-Adressierung.

SOAP vs REST?

Einer der Hauptvorteile von SOAP besteht darin, dass Sie eine WSDL-Dienstbeschreibung haben. Sie können den Dienst ziemlich automatisch erkennen und einen verwendbaren Clientproxy aus dieser Dienstbeschreibung generieren (generieren Sie die Dienstaufrufe, die erforderlichen Datentypen für die Methoden usw.). Beachten Sie, dass WSDL mit Version 2.0 alle HTTP-Verben unterstützt und auch zum Dokumentieren von RESTful-Services verwendet werden kann, aber zu diesem Zweck gibt es eine weniger ausführliche Alternative in WADL (Web Application Description Language).

Bei RESTful-Diensten wird die Nachrichtensicherheit vom Transportprotokoll (HTTPS) bereitgestellt und ist nur Punkt-zu-Punkt. Es verfügt nicht über ein Standard-Messaging-System und erwartet von den Clients, dass sie Kommunikationsfehler beheben, indem sie es erneut versuchen. SOAP verfügt über eine erfolgreiche / Wiederholungslogik und bietet End-to-End-Zuverlässigkeit auch über SOAP-Intermediäre.

Einer der Hauptvorteile von RESTful API besteht darin, dass es flexibel für die Datendarstellung ist. Sie können beispielsweise Ihre Daten im XML- oder JSON-Format serialisieren. RESTful-APIs sind sauberer oder einfacher zu verstehen, da sie ein Element der Verwendung von standardisierten URIs hinzufügen und dem verwendeten HTTP-Verb Bedeutung geben (d. H. GET, POST, PUT und DELETE).

RESTful-Services sind auch leichtgewichtig, das heißt, sie haben nicht viel zusätzliches XML-Markup. Um RESTful API aufzurufen, benötigen Sie lediglich einen Browser oder einen HTTP-Stack. Das ist bei jedem Gerät und jeder Maschine der Fall, das mit einem Netzwerk verbunden ist.

Vorteile von REST

  • Da REST Standard-HTTP verwendet, ist es in fast jeder Hinsicht einfacher. Durch die Erstellung von Clients und die Entwicklung von APIs ist die Dokumentation viel einfacher zu verstehen und es gibt nicht viele Dinge, die REST nicht einfacher / besser macht als SOAP.
  • REST erlaubt viele verschiedene Datenformate, während SOAP nur XML erlaubt. Obwohl dies den Eindruck erweckt, dass es REST Komplexität hinzufügt, weil Sie mit mehreren Formaten arbeiten müssen, war es nach meiner Erfahrung sehr nützlich. JSON eignet sich normalerweise besser für Daten und Parsen viel schneller. REST ermöglicht aufgrund seiner Unterstützung für JSON eine bessere Unterstützung für Browser-Clients.
  • REST bietet eine bessere Leistung und Skalierbarkeit. REST-Lesevorgänge können zwischengespeichert werden; SOAP-basierte Lesevorgänge können nicht zwischengespeichert werden.
  • Keine teuren Tools erfordern die Interaktion mit dem Web-Service
  • Kleinere Lernkurve
  • Effizient (SOAP verwendet XML für alle Nachrichten, REST kann kleinere Nachrichtenformate verwenden)
  • Schnell (keine umfangreiche Verarbeitung erforderlich)
  • Näher zu anderen Webtechnologien in der Designphilosophie

Vorteile von SOAP

  • WS-Sicherheit: Während SOAP SSL (genau wie REST) ​​unterstützt, unterstützt es auch WS-Security, die einige Sicherheitsfunktionen des Unternehmens hinzufügt. Unterstützt die Identität durch Intermediäre, nicht nur Punkt zu Punkt (SSL). Es bietet auch eine Standardimplementierung von Datenintegrität und Datenschutz. "Enterprise" heißt nicht, dass es sicherer ist, es unterstützt einfach einige Sicherheitstools, die typische Internetdienste nicht benötigen, sondern sie werden nur in einigen "Unternehmensszenarien" benötigt.
  • WS-AtomTransaktion: Benötigen Sie ACID-Transaktionen über einen Service, benötigen Sie SOAP. Während REST Transaktionen unterstützt, ist es nicht so umfassend und nicht ACID-konform. Glücklicherweise machen ACID-Transaktionen im Internet fast nie Sinn. REST wird durch HTTP selbst begrenzt, das keine zweiphasige Festschreibung über verteilte Transaktionsressourcen bereitstellen kann, aber SOAP kann. Internet-Apps benötigen dieses Maß an Transaktionszuverlässigkeit nicht, Enterprise-Apps manchmal.
  • WS-ReliableMessaging: Rest verfügt nicht über ein Standardnachrichtensystem und erwartet von Clients, dass sie Kommunikationsfehler beheben, indem sie es erneut versuchen. SOAP verfügt über eine erfolgreiche / Wiederholungslogik und bietet End-to-End-Zuverlässigkeit auch über SOAP-Intermediäre.
  • Unabhängig von Sprache, Plattform und Transport (REST erfordert die Verwendung von HTTP)
  • Funktioniert gut in verteilten Unternehmensumgebungen (REST setzt direkte Punkt-zu-Punkt-Kommunikation voraus)
  • Standardisiert
  • Bietet eine erhebliche Erweiterbarkeit vor dem Build in Form der WS-Standards
  • Integrierte Fehlerbehandlung
  • Automatisierung bei Verwendung mit bestimmten Sprachprodukten

Wo kann ich REST verwenden? 

Bereiche, in denen REST gut funktioniert, sind:

  • Begrenzte Bandbreite und Ressourcen: Denken Sie daran, die Rückgabestruktur ist wirklich in jedem Format (Entwickler definiert). Außerdem kann jeder Browser verwendet werden, da der REST-Ansatz die standardmäßigen Verben GET, PUT, POST und DELETE verwendet. Denken Sie daran, dass REST auch das XMLHttpRequest-Objekt verwenden kann, das von den meisten modernen Browsern unterstützt wird und einen zusätzlichen AJAX-Bonus bietet.
  • Staatenlose Operationen: Wenn eine Operation fortgesetzt werden muss, ist REST nicht der beste Ansatz und SOAP passt besser dazu. Wenn Sie jedoch zustandslose CRUD-Operationen (Create, Read, Update und Delete) benötigen, dann ist es REST.
  • Caching-Situationen: Wenn die Information aufgrund der zustandslosen Operation des REST-Ansatzes zwischengespeichert werden kann, ist dies perfekt.

Wo kann man SOAP verwenden?

Bereiche, in denen SOAP eine großartige Lösung darstellt:

  • Asynchrone Verarbeitung und Aufruf: Wenn Ihre Anwendung ein garantiertes Maß an Zuverlässigkeit und Sicherheit benötigt, bietet SOAP 1.2 zusätzliche Standards, um diese Art von Betrieb zu gewährleisten. Dinge wie WSRM - WS-Reliable Messaging.
  • Formale Verträge: Wenn beide Seiten (Anbieter und Verbraucher) sich auf das Austauschformat einigen müssen, gibt SOAP 1.2 die starren Spezifikationen für diese Art der Interaktion an.
  • Stateful Operationen: Wenn die Anwendung kontextabhängige Informationen und die Verwaltung von Konversationszuständen benötigt, verfügt SOAP 1.2 über die zusätzliche Spezifikation in der WS-Struktur, um diese Dinge zu unterstützen (Sicherheit, Transaktionen, Koordination usw.). Im Vergleich dazu würde der REST-Ansatz die Entwickler dazu bringen, diese benutzerdefinierten Installationen zu erstellen.

43
2018-04-21 11:12



Unterschied zwischen Rest und Soap

SEIFE

  1. SOAP ist ein Protokoll.
  2. SOAP steht für Simple Object Access Protocol.
  3. SOAP kann REST nicht verwenden, da es sich um ein Protokoll handelt.
  4. SOAP verwendet Service-Schnittstellen, um die Geschäftslogik verfügbar zu machen.
  5. SOAP definiert streng zu befolgende Standards.
  6. SOAP benötigt mehr Bandbreite und Ressourcen als REST.
  7. SOAP definiert seine eigene Sicherheit.
  8. SOAP erlaubt nur XML-Datenformat.
  9. SOAP ist weniger bevorzugt als REST.

SICH AUSRUHEN

  1. REST ist ein architektonischer Stil.
  2. REST steht für Representational State Transfer.
  3. REST kann SOAP-Webdienste verwenden, weil es ein Konzept ist und jedes Protokoll wie HTTP, SOAP verwenden kann.
  4. REST verwendet URI, um Geschäftslogik verfügbar zu machen.
  5. REST definiert nicht zu viele Standards wie SOAP.
  6. REST benötigt weniger Bandbreite und Ressourcen als SOAP.
  7. RESTful-Webdienste erben Sicherheitsmaßnahmen vom zugrunde liegenden Transport.
  8. REST erlaubt verschiedene Datenformate wie Klartext, HTML, XML, JSON etc.
  9. REST bevorzugter als SOAP.

Für mehr Details sehen Sie bitte Hier


29
2018-03-21 12:47



IMHO können Sie nicht SOAP und REST vergleichen, wo diese zwei verschiedene Dinge sind.

SEIFEist ein Protokoll und SICH AUSRUHEN ist ein Software-Architekturmuster. Es gibt viele Missverständnisse im Internet für SOAP vs REST.

SEIFE definiert XML-basiertes Nachrichtenformat, das von Web-Service-fähigen Anwendungen verwendet wird, um sich gegenseitig über das Internet zu kommunizieren. Um dies zu tun, benötigen die Anwendungen Vorwissen über den Nachrichtenvertrag, Datentypen, etc ..

SICH AUSRUHEN stellt den Status (als Ressourcen) eines Servers von einer URL dar. Er ist zustandslos und Clients sollten nicht über das Vorwissen verfügen, um mit dem Server zu interagieren, außer über das Verständnis von Hypermedia hinaus.


12
2018-01-17 00:17



Zusatz für:

++ Ein Fehler, der oft bei der Annäherung an REST gemacht wird, ist "Web Services mit URLs" - REST als RPC-Mechanismus (RPC = Remote Procedure Call), wie SOAP, aber ohne HTTP-URL und ohne SOAP XML-Namespaces

++ Im Gegensatz dazu hat REST mit RPC wenig zu tun. Während RPC serviceorientiert ist und sich auf Aktionen und Verben konzentriert, ist REST ressourcenorientiert und betont die Dinge und Substantive, aus denen eine Anwendung besteht.


5
2017-09-20 08:02