Representational State Transfer (REST) und Simple Object Access Protocol (SOAP)

Question

Kann mir jemand erklären, was das ist? REST und was ist SOAP in einfachem Englisch? Und wie funktionieren Webdienste?

Answer 1

Einfache Erklärung zu SOAP und REST

SOAP - "Einfaches Objektzugriffsprotokoll".

SOAP ist eine Methode zur Übertragung von Nachrichten oder kleinen Mengen von Informationen über das Internet. SOAP-Nachrichten sind in XML formatiert und werden in der Regel über HTTP (Hypertext Transfer Protocol) gesendet.

---

Rest - Repräsentative Zustandsübertragung

Rest ist ein einfaches Verfahren zum Senden und Empfangen von Daten zwischen Client und Server, für das nicht viele Standards definiert sind. Sie können Daten als JSON, XML oder sogar einfachen Text senden und empfangen. Im Vergleich zu SOAP ist es leichtgewichtig.

---

Answer 2

Beide Methoden werden von vielen der großen Akteure angewandt. Es ist eine Frage der Vorliebe. Ich bevorzuge REST, weil es einfacher zu verwenden und zu verstehen ist.

Simple Object Access Protocol (SOAP):

• SOAP ist ein XML-Protokoll, das auf HTTP oder manchmal auch auf TCP/IP aufbaut.
• SOAP beschreibt Funktionen und Datentypen.
• SOAP ist ein Nachfolger von XML-RPC und ist sehr ähnlich, beschreibt aber eine standardisierte Art der Kommunikation.
• Mehrere Programmiersprachen unterstützen SOAP von Haus aus. In der Regel füttert man sie mit einer Webservice-URL und kann die Webservice-Funktionen aufrufen, ohne dass spezieller Code erforderlich ist.
• Binäre Daten, die gesendet werden, müssen zunächst in ein Format wie base64 kodiert werden.
• Es gibt mehrere Protokolle und Technologien, die damit zusammenhängen: WSDL, XSDs, SOAP, WS-Adressierung

Repräsentative Zustandsübertragung (REST):

• REST muss nicht über HTTP laufen, aber die meisten meiner folgenden Punkte haben einen HTTP-Bezug.
• REST ist sehr leichtgewichtig, es sagt, Moment mal, wir brauchen diese ganze Komplexität, die SOAP geschaffen hat, nicht.
• Verwendet in der Regel normale HTTP-Methoden anstelle eines großen XML-Formats, das alles beschreibt. Um zum Beispiel eine Ressource zu erhalten, verwenden Sie HTTP GET, um eine Ressource auf dem Server abzulegen, verwenden Sie HTTP PUT. Um eine Ressource auf dem Server zu löschen, verwenden Sie HTTP DELETE.
• REST ist ein sehr einfaches Verfahren, bei dem die HTTP-Methoden GET, POST und PUT zur Aktualisierung von Ressourcen auf dem Server verwendet werden.
• REST wird in der Regel am besten verwendet mit Ressourcenorientierte Architektur (ROA). In dieser Denkweise ist alles eine Ressource, und Sie würden mit diesen Ressourcen arbeiten.
• Solange Ihre Programmiersprache über eine HTTP-Bibliothek verfügt, was bei den meisten der Fall ist, können Sie ein REST-HTTP-Protokoll sehr einfach nutzen.
• Binäre Daten oder binäre Ressourcen können einfach auf Anfrage geliefert werden.

Es gibt endlose Debatten über REST vs. SOAP bei Google .

Mein Favorit ist dieser hier . Update 27 Nov 2013: Die Website von Paul Prescod scheint offline gegangen zu sein und dieser Artikel ist nicht mehr verfügbar, Kopien können jedoch auf der Wiederherstellungsmaschine oder als PDF-Datei unter CiteSeerX .

Answer 3

REST

Soweit ich weiß, ist die Grundidee von REST sehr einfach. Wir verwenden seit Jahren Webbrowser und haben gesehen, wie einfach, flexibel, leistungsstark usw. Websites sind. HTML-Websites verwenden Hyperlinks und Formulare als Hauptmittel der Benutzerinteraktion. Ihr Hauptziel ist es, dass wir, die Kunden, nur die Links kennen, die wir im aktuellen Zustand verwenden können . Und REST sagt einfach: "Warum sollten wir nicht die gleichen Prinzipien nutzen, um Computer statt menschliche Clients durch unsere Anwendung zu steuern? Kombiniert man dies mit der Leistungsfähigkeit der WWW-Infrastruktur, so erhält man ein hervorragendes Werkzeug für die Entwicklung großartiger verteilter Anwendungen.

Eine andere mögliche Erklärung ist für mathematisch denkende Menschen. Jede Anwendung ist im Grunde ein Zustandsautomat, wobei die Aktionen der Geschäftslogik Zustandsübergänge sind. Die Idee von REST besteht darin, jeden Übergang auf eine Anfrage an eine Ressource abzubilden und den Clients Links zur Verfügung zu stellen, die die im aktuellen Zustand verfügbaren Übergänge darstellen. Auf diese Weise wird der Zustandsautomat über Darstellungen und Links modelliert. Aus diesem Grund heißt es REpresentational State Transfer.

Es ist ziemlich überraschend, dass sich alle Antworten entweder auf das Nachrichtenformat oder auf die Verwendung von HTTP-Verben zu konzentrieren scheinen. Tatsächlich spielt das Nachrichtenformat überhaupt keine Rolle, REST kann jedes beliebige Format verwenden, vorausgesetzt, der Entwickler des Dienstes dokumentiert es. HTTP-Verben machen einen Dienst nur zu einem CRUD-Dienst, aber noch nicht zu einem RESTful-Dienst. Was einen Dienst wirklich zu einem REST-Dienst macht, sind Hyperlinks (auch bekannt als Hypermedia-Steuerelemente), die zusammen mit Daten in die Serverantworten eingebettet sind, und ihre Anzahl muss so groß sein, dass jeder Client die nächste Aktion aus diesen Links auswählen kann.

Leider ist es ziemlich schwierig, korrekte Informationen über REST im Web zu finden, mit Ausnahme der Roy Fieldings These . (Er ist derjenige, der REST abgeleitet hat). Ich würde empfehlen, die Buch 'REST in der Praxis da es eine umfassende Schritt-für-Schritt-Anleitung für die Umstellung von SOAP auf REST enthält.

SOAP

Dies ist eine der möglichen Formen der RPC-Architektur (Remote Procedure Call). Im Wesentlichen handelt es sich dabei um eine Technologie, die es den Clients ermöglicht, Methoden des Servers über Dienstgrenzen (Netzwerk, Prozesse usw.) aufzurufen, als ob sie lokale Methoden aufrufen würden. Natürlich unterscheidet sie sich vom Aufruf lokaler Methoden in Bezug auf Geschwindigkeit, Zuverlässigkeit und so weiter, aber die Idee ist so einfach.

Verglichen

Die Details wie Transportprotokolle, Nachrichtenformate, xsd, wsdl usw. spielen keine Rolle, wenn man eine Form von RPC mit REST vergleicht. Der Hauptunterschied besteht darin, dass ein RPC-Dienst das Fahrrad neu erfindet, indem er ein eigenes Anwendungsprotokoll in der RPC-API mit einer Semantik entwickelt, die nur er kennt. Daher müssen alle Clients dieses Protokoll verstehen, bevor sie den Dienst nutzen können, und es kann keine generische Infrastruktur wie Caches aufgebaut werden, da die Semantik aller Anfragen proprietär ist. Außerdem geben RPC-APIs keine Hinweise darauf, welche Aktionen im aktuellen Zustand erlaubt sind; dies muss aus zusätzlicher Dokumentation abgeleitet werden. Bei REST hingegen werden einheitliche Schnittstellen verwendet, damit verschiedene Clients ein gewisses Verständnis der API-Semantik haben, und Hypermedia-Steuerelemente (Links), um die verfügbaren Optionen in jedem Zustand hervorzuheben. Auf diese Weise können Antworten auf skalierbare Dienste zwischengespeichert werden, und die korrekte Verwendung der API ist ohne zusätzliche Dokumentation leicht zu ermitteln.

In gewisser Weise ist SOAP (wie jede andere RPC) ein Versuch, eine Dienstgrenze zu durchtunneln, wobei das Verbindungsmedium als Blackbox behandelt wird, die nur Nachrichten übertragen kann. REST ist eine Entscheidung, anzuerkennen, dass das Web ein riesiges verteiltes Informationssystem ist, die Welt so zu akzeptieren, wie sie ist, und zu lernen, sie zu beherrschen, anstatt sie zu bekämpfen.

SOAP scheint sich hervorragend für interne Netzwerk-APIs zu eignen, wenn Sie sowohl den Server als auch die Clients kontrollieren und die Interaktionen nicht allzu komplex sind. Für Entwickler ist es natürlicher, es zu verwenden. Für eine öffentliche API, die von vielen unabhängigen Parteien genutzt wird, komplex und groß ist, sollte REST jedoch besser geeignet sein. Aber dieser letzte Vergleich ist sehr unscharf.

Update

Meiner Erfahrung nach ist die Entwicklung von REST unerwartet schwieriger als die von SOAP. Zumindest für .NET. Es gibt zwar großartige Frameworks wie ASP.NET Web API, aber es gibt keine Tools, die automatisch einen clientseitigen Proxy generieren würden. Es gibt nichts wie 'Add Web Service Reference' oder 'Add WCF Service Reference'. Man muss den gesamten Serialisierungs- und Dienstabfragecode von Hand schreiben. Und Mann, das ist eine Menge Kesselstein-Code. Ich denke, die REST-Entwicklung braucht etwas Ähnliches wie WSDL und eine Tooling-Implementierung für jede Entwicklungsplattform. In der Tat scheint es eine gute Grundlage zu geben: WADL ou WSDL 2.0 aber keine der beiden Normen scheint gut begründet zu sein.

Aktualisierung (Jan 2016)

Wie sich herausstellte, gibt es jetzt eine große Auswahl an Werkzeugen für die Definition der REST-API. Meine persönliche Präferenz ist derzeit RAML .

Wie Webdienste funktionieren

Nun, diese Frage ist zu weit gefasst, denn sie hängt von der Architektur und der Technologie ab, die in dem jeweiligen Webdienst verwendet wird. Aber im Allgemeinen ist ein Webdienst einfach eine Anwendung im Web, die Anfragen von Kunden annehmen und Antworten zurücksenden kann. Er ist dem Web ausgesetzt, also ist er ein Web Dienst, der in der Regel rund um die Uhr verfügbar ist. Dienstleistung . Natürlich löst er für seine Kunden ein Problem (warum sonst sollte jemand einen Webdienst nutzen).

Answer 4

Dies ist die einfachste Erklärung, die Sie je finden werden.

Dieser Artikel ist eine Erzählung von Mann zu Frau, in der der Ehemann seiner Frau REST erklärt, und zwar in reinem Laiendeutsch. Unbedingt lesen!

Wie-ich-meiner-Frau-den-Ruhestand-erklärt habe (Original-Link)
Wie-ich-meiner-Frau-den-Ruhestand-erklärt habe (2013-07-19 funktionierender Link)

Answer 5

SOAP - Einfaches Objektzugriffsprotokoll は Protokoll !

REST - REpresentational State Transfer ist eine Baustil !

SOAP ist ein XML-Protokoll, das zur Übertragung von Nachrichten verwendet wird, normalerweise über HTTP

REST et SOAP sind wohl no sich gegenseitig ausschließen. Eine RESTful-Architektur könnte Folgendes verwenden HTTP ou SOAP oder ein anderes Kommunikationsprotokoll. REST ist für das Web optimiert und daher HTTP ist eine perfekte Wahl. HTTP ist auch die nur Protokolls, das im Beitrag von Roy Fielding diskutiert wird.

REST und SOAP sind zwar sehr unterschiedlich, aber die Frage beleuchtet die Tatsache, dass REST et HTTP werden häufig gemeinsam verwendet. Dies ist in erster Linie auf die Einfachheit von HTTP und seine sehr natürliche Zuordnung zu den RESTful-Grundsätzen zurückzuführen.

Grundlegende REST-Prinzipien

Client-Server-Kommunikation

Client-Server-Architekturen haben eine sehr ausgeprägte Trennung von Belangen. Alle im RESTful-Stil erstellten Anwendungen müssen prinzipiell auch Client-Server sein.

Zustandslos

Bei jeder Anfrage eines Clients an den Server muss sein Zustand vollständig dargestellt werden. Der Server muss in der Lage sein, die Client-Anfrage vollständig zu verstehen, ohne einen Server-Kontext oder einen Server-Sitzungsstatus zu verwenden. Daraus folgt, dass der gesamte Zustand auf dem Client gehalten werden muss. Auf die zustandslose Darstellung wird später noch näher eingegangen.

Cachefähig

Es können Cache-Beschränkungen verwendet werden, so dass Antwortdaten als cachefähig oder nicht cachefähig gekennzeichnet werden können. Alle als cachefähig gekennzeichneten Daten können als Antwort auf dieselbe nachfolgende Anfrage wiederverwendet werden.

Einheitliche Schnittstelle

Alle Komponenten müssen über eine einzige einheitliche Schnittstelle interagieren. Da die gesamte Interaktion der Komponenten über diese Schnittstelle erfolgt, ist die Interaktion mit verschiedenen Diensten sehr einfach. Die Schnittstelle ist die gleiche! Das bedeutet auch, dass Implementierungsänderungen isoliert vorgenommen werden können. Solche Änderungen haben keine Auswirkungen auf die grundlegende Interaktion der Komponenten, da die einheitliche Schnittstelle immer unverändert bleibt. Ein Nachteil ist, dass man an die Schnittstelle gebunden ist. Wenn ein bestimmter Dienst durch eine Änderung der Schnittstelle optimiert werden könnte, hat man Pech gehabt, denn REST verbietet dies. Positiv ist jedoch, dass REST für das Web optimiert ist, daher die unglaubliche Beliebtheit von REST über HTTP!

Die oben genannten Konzepte stellen definierende Merkmale von REST dar und unterscheiden die REST-Architektur von anderen Architekturen wie Webservices. Es ist sinnvoll, darauf hinzuweisen, dass ein REST-Dienst ein Webdienst ist, ein Webdienst aber nicht notwendigerweise ein REST-Dienst ist.

Siehe diesen Blog Beitrag sur REST-Konstruktionsprinzipien für weitere Informationen über REST und die oben genannten Kugeln.