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

Kann jemand erklären, was REST ist und was ist SOAP in einfachem Englisch? Und wie funktionieren Web Services?

    Einfache Erklärung über SOAP und REST

    SOAP – “Einfaches Objektzugriffsprotokoll”

    SOAP ist eine Methode, um Nachrichten oder kleine Mengen von Informationen über das Internet zu übertragen. SOAP-Nachrichten sind in XML formatiert und werden in der Regel über HTTP (Hypertext Transfer Protocol) gesendet.


    Rest – Representational State Transfer

    Rest ist eine einfache Methode zum Senden und Empfangen von Daten zwischen Client und Server und es sind nicht viele Standards definiert. Sie können Daten als JSON, XML oder sogar als einfacher Text senden und empfangen. Es ist leicht im Vergleich zu SOAP.


    Bildbeschreibung hier eingeben

    Beide Methoden werden von vielen der großen Spieler verwendet. Es ist eine Frage der Präferenz. Meine Präferenz ist REST, weil es einfacher zu verwenden und zu verstehen ist.

    Einfaches Objektzugriffsprotokoll (SOAP):

    • SOAP erstellt ein XML-Protokoll über HTTP oder manchmal TCP / IP.
    • SOAP beschreibt functionen und Datentypen.
    • SOAP ist ein Nachfolger von XML-RPC und ist sehr ähnlich, beschreibt jedoch einen Standardweg zur Kommunikation.
    • Mehrere Programmiersprachen haben native Unterstützung für SOAP, Sie geben ihm normalerweise eine Web-Service-URL und Sie können seine Web-Service-functionen 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, XSDs, SOAP, WS-Adressierung

    Repräsentative Zustandsübertragung (REST):

    • REST muss nicht über HTTP sein, aber die meisten meiner Punkte unten haben einen HTTP-Bias.
    • REST ist sehr leichtgewichtig, heißt es, warte mal, wir brauchen nicht all die Komplexität, die SOAP erzeugt hat.
    • In der Regel werden normale HTTP-Methoden anstelle eines großen XML-Formats verwendet, das alles beschreibt. Um beispielsweise eine Ressource zu erhalten, verwenden Sie HTTP GET, um eine Ressource auf den Server zu setzen, den Sie HTTP PUT verwenden. Um eine Ressource auf dem Server zu löschen, verwenden Sie HTTP DELETE.
    • REST ist insofern sehr einfach, als HTTP-Methoden GET, POST und PUT zum Aktualisieren von Ressourcen auf dem Server verwendet werden.
    • REST wird normalerweise am besten mit der Resource Oriented Architecture (ROA) verwendet. In dieser Denkweise ist alles eine Ressource, und Sie würden mit diesen Ressourcen arbeiten.
    • Solange Ihre Programmiersprache über eine HTTP-Bibliothek verfügt und die meisten dies tun, können Sie sehr einfach ein REST-HTTP-Protokoll verwenden.
    • Binäre Daten oder binäre Ressourcen können einfach auf Anfrage geliefert werden.

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

    Mein Favorit ist dieser . Update 27. November 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 Wayback Machine oder als PDF bei CiteSeerX gefunden werden .

    SICH AUSRUHEN

    Ich verstehe die Grundidee von REST ist extrem einfach. Wir verwenden seit Jahren Webbrowser und wir haben gesehen, wie einfach, flexibel, performant etc. Websites sind. HTML-Sites verwenden Hyperlinks und Formulare als primäres Mittel der Benutzerinteraktion. Ihr Hauptziel ist es, uns Kunden nur die Links zu zeigen, die wir im aktuellen Zustand verwenden können . Und REST sagt einfach “warum nicht die gleichen Prinzipien verwenden, um Computer anstelle von menschlichen Kunden durch unsere Anwendung zu fahren?” Kombinieren Sie dies mit der performance der WWW-Infrastruktur und Sie erhalten ein hervorragendes Tool zum Erstellen großartiger verteilter Anwendungen.

    Eine andere mögliche Erklärung ist für mathematisch denkende Menschen. Jede Anwendung ist im Grunde eine Zustandsmaschine mit Geschäftslogikaktionen, die Zustandsübergänge sind. Die Idee von REST besteht darin, jeden Übergang auf eine Anfrage an eine Ressource zuzuordnen und den Clients Links zur Verfügung zu stellen, die Übergänge darstellen, die im aktuellen Zustand verfügbar sind. So modelliert es die Zustandsmaschine über Repräsentationen und Verbindungen. Deshalb 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 konzentrieren. In der Tat spielt das Nachrichtenformat keine Rolle, REST kann jedes verwenden, sofern der Serviceentwickler es dokumentiert. HTTP-Verben machen einen Dienst nur zu einem CRUD-Dienst, aber noch nicht RESTful. Was einen Dienst wirklich in einen REST-Dienst verwandelt, sind Hyperlinks (auch Hypermedia-Steuerelemente genannt), die zusammen mit Daten in Serverantworten eingebettet sind und deren Menge ausreicht, damit jeder Client die nächste Aktion aus diesen Links auswählen kann.

    Leider ist es ziemlich schwierig, korrekte Informationen zu REST im Web zu finden, mit Ausnahme der These von Roy Fielding . (Er ist derjenige, der REST abgeleitet hat). Ich würde das Buch “REST in Practice” empfehlen , da es eine umfassende Schritt-für-Schritt-Anleitung zur Entwicklung von SOAP zu REST gibt.

    SEIFE

    Dies ist eine der möglichen Formen des RPC-Architekturstils (Remoteprozeduraufruf). Im Wesentlichen ist es nur eine Technologie, die es Clients ermöglicht, Methoden des Servers über Dienstgrenzen (Netzwerk, processe usw.) aufzurufen, als ob sie lokale Methoden aufrufen würden. Natürlich unterscheidet es sich vom Aufruf lokaler Methoden in Bezug auf Geschwindigkeit, Zuverlässigkeit usw., aber die Idee ist so einfach.

    Verglichen

    Die Details wie Transportprotokolle, Nachrichtenformate, xsd, wsdl usw. sind beim Vergleich einer beliebigen Form von RPC mit REST nicht von Bedeutung. Der Hauptunterschied besteht darin, dass ein RPC-Dienst das Fahrrad neu erfindet, indem er sein eigenes Anwendungsprotokoll in der RPC-API mit der nur ihm bekannten Semantik gestaltet. Daher müssen alle Clients dieses Protokoll vor der Verwendung des Dienstes verstehen, und keine generische Infrastruktur wie Caches kann aufgrund der proprietären Semantik aller Anforderungen erstellt werden. Darüber hinaus schlagen RPC-APIs nicht vor, welche Aktionen in dem aktuellen Status zulässig sind, dies muss aus zusätzlicher Dokumentation abgeleitet werden. REST hingegen impliziert die Verwendung einheitlicher Schnittstellen, um verschiedenen Clients ein Verständnis für die API-Semantik und Hypermedia-Steuerelemente (Verknüpfungen) zu ermöglichen, um verfügbare Optionen in jedem Zustand hervorzuheben. Daher können Caching-Antworten verwendet werden, um Services zu skalieren und die korrekte API-Nutzung ohne zusätzliche Dokumentation leicht erkennbar zu machen.

    In gewisser Weise ist SOAP (wie jeder andere RPC) ein Versuch, durch eine Dienstgrenze zu tunneln, wobei die verbindenden Medien als eine Black Box behandelt werden, die nur Nachrichten übertragen kann. REST ist eine Entscheidung, die anerkennt, dass das Web ein riesiges verteiltes Informationssystem ist, um die Welt so zu akzeptieren, wie sie ist, und lernen, sie zu meistern, statt dagegen zu kämpfen.

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

    Aktualisieren

    Meine Erfahrung hat unerwartet gezeigt, dass REST-Entwicklung schwieriger als SOAP ist. Zumindest für .NET. Obwohl es großartige Frameworks wie die ASP.NET-Web-API gibt, gibt es keine Tools, die automatisch clientseitige Proxy generieren würden. Nichts wie “Add Web Service Reference” oder “Add WCF Service Reference”. Man muss alle Serialisierungs- und Dienstabfragecodes von Hand schreiben. Und Mann, das ist eine Menge Code. Ich denke, dass die REST-Entwicklung etwas Ähnliches wie die WSDL- und Werkzeugimplementierung für jede Entwicklungsplattform benötigt. In der Tat scheint es einen guten Grund zu geben: WADL oder WSDL 2.0 , aber keiner der Standards scheint gut unterstützt zu werden.

    Aktualisierung (Januar 2016)

    Es gibt nun eine Vielzahl von Tools für die REST-API-Definition. Meine persönliche Vorliebe ist momentan RAML .

    Wie funktionieren Web Services?

    Nun, das ist eine zu weit gefasste Frage, weil sie von der Architektur und der Technologie abhängt, die in dem spezifischen Webdienst verwendet werden. Aber im Allgemeinen ist ein Webdienst einfach eine Anwendung im Web, die Anfragen von Clients annehmen und Antworten zurückgeben kann. Es ist dem Web ausgesetzt, also ist es ein Web- Service, und es ist normalerweise rund um die Uhr verfügbar, deshalb ist es ein Service . Natürlich triggers es ein Problem (warum sollte jemand jemals einen Web-Service benutzen) für seine Kunden.

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

    Dieser Artikel nimmt einen Ehemann zur Ehefrauerzählung, in der der Ehemann seiner Frau über REST in rein laienhaften Begriffen erklärt. Muss lesen!

    Wie-ich-erklärt-Rest-zu-meiner-Frau (Original-Link)
    How-i-erklärt-Rest-zu-meiner-Frau (2013-07-19 Arbeitslink)

    SOAP – Simple Object Access Protocol ist ein Protokoll !

    REST – Representational State Transfer ist ein architektonischer Stil !

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

    REST und SOAP sich wohl nicht gegenseitig aus. Eine REST-konforme Architektur kann HTTP oder SOAP oder ein anderes Kommunikationsprotokoll verwenden. REST ist für das Web optimiert und somit ist HTTP eine perfekte Wahl. HTTP ist auch das einzige Protokoll, das in Roy Fieldings Arbeit diskutiert wird.

    Obwohl REST und SOAP eindeutig sehr unterschiedlich sind, beleuchtet die Frage die Tatsache, dass REST und HTTP oft im Tandem verwendet werden. 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 Anwendungen, die im RESTful-Stil erstellt werden, müssen grundsätzlich 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. Wir werden später die staatenlose Repräsentation ausführlicher behandeln.

    Zwischenspeicherbar

    Cache-Beschränkungen können verwendet werden, wodurch es ermöglicht wird, Antwortdaten als zwischenspeicherbar oder nicht-abspeicherbar zu markieren. 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.

    Weitere Informationen zu REST und den oben genannten Aufzählungszeichen finden Sie in diesem Blogbeitrag zu REST Design Principals .

    Ich mag Brian R. Bondys Antwort. Ich wollte nur hinzufügen, dass Wikipedia eine klare Beschreibung von REST bietet. Der Artikel unterscheidet es von SOAP.

    REST ist ein Austausch von Zustandsinformationen, der so einfach wie möglich durchgeführt wird.

    SOAP ist ein Nachrichtenprotokoll, das XML verwendet.

    Einer der Hauptgründe dafür, dass viele Benutzer von SOAP zu REST gewechselt sind, ist, dass die mit SOAP-basierten Webdiensten verbundenen WS- * (WS-splat) Standards EXTREM kompliziert sind. Eine Liste der Spezifikationen finden Sie in Wikipedia . Jede dieser Spezifikationen ist sehr kompliziert.

    EDIT: aus irgendeinem Grund werden die Links nicht korrekt angezeigt. REST = http://en.wikipedia.org/wiki/REST

    WS- * = http://en.wikipedia.org/wiki/WS- *

    Sowohl SOAP-Webservices als auch REST-Webservices können das HTTP-Protokoll und andere Protokolle verwenden (um nur SOAP zu nennen, kann das zugrunde liegende Protokoll von REST sein). Ich werde nur über das HTTP-Protokoll SOAP und REST sprechen, da dies die häufigste Verwendung von ihnen ist.

    SEIFE

    SOAP (“einfaches” Objektzugriffsprotokoll) ist ein Protokoll (und ein W3C-Standard ). Es definiert, wie SOAP-Nachrichten erstellt, gesendet und verarbeitet werden.

    • SOAP-Nachrichten sind XML-Dokumente mit einer bestimmten Struktur: Sie enthalten einen Umschlag, der den Header und den Body-Abschnitt enthält. Der Body enthält die eigentlichen Daten, die wir senden wollen, in einem XML-Format. Es gibt zwei Kodierungsstile , aber wir wählen normalerweise literal , was bedeutet, dass unsere Anwendung oder ihr SOAP-Treiber die XML-Serialisierung und Deserialisierung der Daten durchführt.

    • SOAP-Nachrichten werden als HTTP-Nachrichten mit dem SOAP + XML MIME-Subtyp weitergeleitet. Diese HTTP-Nachrichten können mehrteilig sein, daher können wir optional Dateien an SOAP-Nachrichten anhängen.

    • Offensichtlich verwenden wir eine Client-Server-Architektur, so dass die SOAP-Clients Anfragen an die SOAP-Webserices senden und die Dienste Antworten an die Clients senden. Die meisten Webdienste verwenden eine WSDL-Datei, um den Dienst zu beschreiben. Die WSDL-Datei enthält das XML-Schema (im Folgenden XSD) der zu sendenden Daten und die WSDL-Bindung, die definiert, wie der Webdienst an das HTTP-Protokoll gebunden ist. Es gibt zwei Bindungsarten : RPC und Dokument. Durch die RPC-Style-Bindung enthält der SOAP-Body die Darstellung eines Operationsaufrufs mit den Parametern (HTTP-Requests) oder den Rückgabewerten (HTTP Response). Die Parameter und Rückgabewerte werden anhand der XSD validiert. Durch die Bindung des Dokument-Styles enthält der SOAP-Body ein XML-Dokument, das gegen das XSD validiert wird. Ich denke, dass der Bindungsstil für Dokumente besser für ereignisbasierte Systeme geeignet ist, aber ich habe diesen Bindungsstil nie verwendet. Der RPC-Bindungsstil ist häufiger, sodass die meisten Benutzer SOAP für XML / RPC-Zwecke durch verteilte Anwendungen verwenden. Die Webservices finden sich normalerweise gegenseitig, indem sie einen UDDI- Server fragen. UDDI-Server sind Registries, die den Standort der Webservices speichern.

    SOAP RPC

    Der meiner Meinung nach am weitesten verbreitete SOAP-Webservice verwendet den RPC-Bindungsstil und den Literal-Codierungsstil und hat folgende Eigenschaften:

    • Es ordnet URLs Operationen zu.
    • Er sendet Nachrichten mit dem SOAP + XML MIME-Subtyp.
    • Es kann einen serverseitigen Sitzungsspeicher haben, dafür gibt es keine Einschränkungen.
    • Die SOAP-Clienttreiber verwenden die WSDL-Datei des Dienstes, um die RPC-Vorgänge in Methoden zu konvertieren. Die clientseitige Anwendung kommuniziert mit dem SOAP-Webservice, indem sie diese Methoden aufruft. Daher brechen die meisten SOAP-Clients durch Schnittstellenänderungen (resultierende Methodennamen und / oder Parameteränderungen).
    • Es ist möglich, SOAP-Clients zu schreiben, die nicht durch Schnittstellenänderungen mit RDF brechen und Operationen durch Semantik finden, aber semantischer Webservice ist sehr selten und sie haben nicht notwendigerweise einen nicht brechenden Client (schätze ich).

    SICH AUSRUHEN

    REST (Representational State Transfer) ist ein Architekturstil, der in der Dissertation von Roy Fielding beschrieben wird. Es geht nicht um Protokolle wie SOAP. Es beginnt mit einem Null-Architektur-Stil ohne Einschränkungen und definiert die Beschränkungen der REST-Architektur einzeln. Leute benutzen den Begriff RESTful für Webservices, die alle REST-Einschränkungen erfüllen, aber laut Roy Fielding gibt es keine solchen Dinge wie REST-Level . Wenn ein Webservice nicht jede einzelne REST-Einschränkung erfüllt, handelt es sich nicht um einen REST-Webservice.

    REST-Einschränkungen

    • Client – Server – Architektur – Ich denke, dieser Teil ist jedem vertraut. Die REST-Clients kommunizieren mit den REST-Webservices, die Webservices verwalten den gemeinsamen Datenressourcenstatus – und dienen diesen Clients.
    • Stateless – Der “State Transfer” -Teil der Abkürzung: REST. Die Clients verwalten den Clientstatus (Sitzungs- / Anwendungsstatus), sodass die Dienste keinen Sitzungsspeicher haben dürfen. Die Clients übertragen den relevanten Teil des Client-Zustands bei jeder Anfrage an die Dienste, die mit dem relevanten Teil des von ihnen gepflegten Ressourcen-Zustands antworten. So haben Anfragen keinen Kontext, sie enthalten immer die notwendigen Informationen, um sie zu verarbeiten. Zum Beispiel durch HTTP-Basisauthentifizierung wird der Benutzername und das Passwort vom Client gespeichert, und er sendet sie bei jeder Anfrage, so dass die Authentifizierung bei jeder Anfrage erfolgt. Dies unterscheidet sich sehr von normalen Webapplikationen, bei denen die Authentifizierung nur durch Login erfolgt. Wir können jeden Client-seitigen Datenspeichermechanismus wie In-Memory (JavaScript), Cookies, LocalStorage und so weiter verwenden, um einige Teile des Client-Status zu erhalten, wenn wir das wollen. Der Grund der Staatenlosigkeitsbeschränkung, dass der Server gut skaliert – selbst bei sehr hoher Last (Millionen von Benutzern) – wenn er nicht die Sitzung jedes einzelnen Clients führen muss.
    • Cache – Die Antwort muss Informationen enthalten, die vom Client zwischengespeichert werden können oder nicht. Dies verbessert die Skalierbarkeit weiter.
    • Einheitliche Schnittstelle

      • Identifizierung von Ressourcen – REST-Ressource ist die gleiche wie RDF- Ressource. Laut Fielding, wenn Sie etwas benennen können, dann kann es eine Ressource sein, zum Beispiel: “Das aktuelle lokale Wetter” kann eine Ressource sein, oder “Ihr Handy” kann eine Ressource sein, oder “ein bestimmtes Web-Dokument” sein kann eine Ressource. Um eine Ressource zu identifizieren, können Sie Ressourcen-IDs verwenden: URLs und URNs (z. B. ISBN-Nummer nach Büchern ). Ein einzelner Bezeichner sollte nur zu einer bestimmten Ressource gehören, aber eine einzelne Ressource kann viele Bezeichner haben, die wir häufig zum Beispiel durch Paginierung mit URLs wie https://example.com/api/v1/users?offset=50&count=25 ausnutzen . URLs haben einige Spezifikationen , z. B. URLs mit den gleichen Pfaden, aber unterschiedliche Abfragen sind nicht identisch, oder der Pfadteil sollte die hierarchischen Daten der URL enthalten und der Abfrageteil sollte die nicht-hierarchischen Daten enthalten. Dies sind die Grundlagen zum Erstellen von URLs durch REST. Übrigens. Die URL-Struktur ist nur für die Serviceentwickler von Bedeutung, ein echter REST-Client hat damit nichts zu tun. Eine weitere häufig gestellte Frage ist die API-Versionierung, die eine einfache ist, da laut Fielding die einzige Konstante bei der Ressource die Semantik ist. Wenn sich die Semantik ändert, können Sie eine neue Versionsnummer hinzufügen. Sie können die klassische 3-Nummern-Versionierung verwenden und den URLs nur die Hauptnummer hinzufügen ( https://example.com/api/v1/ ). Bei rückwärtskompatiblen Änderungen passiert also nichts, bei nicht rückwärtskompatiblen Änderungen haben Sie eine nicht rückwärtskompatible Semantik mit einem neuen API-Stamm https://example.com/api/v2/ . Die alten Clients werden also nicht brechen, weil sie das https://example.com/api/v1/ mit der alten Semantik verwenden können.
      • Manipulation von Ressourcen durch Repräsentationen – Sie können die Daten in Bezug auf Ressourcen (Ressourcenstatus) manipulieren, indem Sie die beabsichtigte Repräsentation der Ressourcen – zusammen mit der HTTP-Methode und der Ressourcen-ID – an den REST-Service senden. Wenn Sie beispielsweise einen Benutzer nach der Hochzeit umbenennen möchten, können Sie eine PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} senden, in der {name: "Mrs Smith"} ist eine JSON-Repräsentation des beabsichtigten Ressourcenstatus, mit anderen Worten: der neue Name. Dies geschieht umgekehrt. Der Dienst sendet Repräsentationen von Ressourcen an die Clients, um deren Zustände zu ändern. Zum Beispiel, wenn wir den neuen Namen lesen wollen, können wir eine GET https://example.com/api/v1/users/1?fields="name" Abrufanforderung senden, die zu einem 200 ok, {name: "Mrs Smith"} Antwort. So können wir diese Darstellung verwenden, um den Client-Status zu ändern, zum Beispiel können wir ein “Willkommen auf unserer Seite Frau Smith!” Botschaft. Eine Ressource kann viele Repräsentationen haben, abhängig von der Ressourcen-ID (URL) oder dem Accept-Header, den wir mit der Anfrage gesendet haben. Zum Beispiel können wir ein Bild von Mrs Smith (wahrscheinlich nicht nackt) senden, wenn image/jpeg angefordert wird.
      • Selbstbeschreibende Nachrichten – Nachrichten müssen Informationen darüber enthalten, wie sie verarbeitet werden. Zum Beispiel URI und HTTP-Methode, Content-Type-Header, Cache-Header, RDF, die die Bedeutung der Daten beschreibt, etc … Es ist wichtig, Standardmethoden zu verwenden. Es ist wichtig, die Spezifikation der HTTP-Methoden zu kennen. Zum Beispiel bedeutet GET das Abrufen von Informationen, die durch die Anforderungs-URL identifiziert werden, DELETE bedeutet, dass der Server aufgefordert wird, die durch die angegebene URL identifizierte Ressource zu löschen, und so weiter … HTTP-Statuscodes haben ebenfalls eine Spezifikation , zum Beispiel 200 bedeutet Erfolg, 201 bedeutet die neue Ressource wurde erstellt, 404 bedeutet, dass die angeforderte Ressource nicht auf dem Server gefunden wurde, usw. Die Verwendung vorhandener Standards ist ein wichtiger Bestandteil von REST.
      • Hypermedia als Motor des Anwendungsstatus (HATEOAS im Folgenden) – Hypermedia ist ein Medientyp, der Hyperlinks enthalten kann. Durch das Web folgen wir Links – die durch ein Hypermedia-Format (normalerweise HTML) beschrieben werden, um ein Ziel zu erreichen, anstatt die URLs in die Adressleiste einzugeben. REST folgt demselben Konzept, die vom Dienst gesendeten Darstellungen können Hyperlinks enthalten. Wir verwenden diese Hyperlinks, um Anfragen an den Dienst zu senden. Mit der Antwort erhalten wir Daten (und wahrscheinlich mehr Links), die wir verwenden können, um den neuen Client-Status zu erstellen, und so weiter. Aus diesem Grund ist Hypermedia der Motor des Anwendungsstatus (Client-Status). Sie fragen sich wahrscheinlich, wie Kunden die Hyperlinks erkennen und ihnen folgen. Von Menschen ist es ziemlich einfach, wir lesen den Titel des Links, füllen vielleicht Eingabefelder und danach nur einen einzigen Klick. Auf Maschinen müssen wir den Links mit RDF (von JSON-LD mit Hydra ) oder mit Hypermedia-spezifischen Lösungen (zum Beispiel IANA-Link-Relationen und herstellerspezifischen MIME-Typen von HAL + JSON ) Semantik hinzufügen. Es gibt viele maschinenlesbare XML- und JSON-Hypermedia-Formate , nur eine kurze Liste von ihnen:

        • XHTML
        • ATOM + XML
        • RDF + XML
        • HAL + XML
        • HAL + JSON
        • JSON-LD
        • RDF + JSON
        • Sirene
        • Sammlung + JSON

        Manchmal ist es schwer zu wählen …

    • Schichtsystem – Wir können mehrere Schichten zwischen den Clients und den Diensten verwenden. Keiner von ihnen sollte von all diesen zusätzlichen Schichten wissen, nur von der Schicht direkt daneben. Diese Layer können die Skalierbarkeit verbessern, indem sie Caches und Load Balancing anwenden oder Sicherheitsrichtlinien erzwingen.
    • Code on demand – Wir können Code zurücksenden, der die functionalität des Clients erweitert, zum Beispiel JavaScript-Code auf einen Browser. Dies ist die einzige optionale Einschränkung von REST.

    REST Webservice – SOAP RPC Webservice Unterschiede

    Ein REST-Webservice unterscheidet sich also erheblich von einem SOAP-Webservice (mit RPC-Bindungsstil und literalem Codierungsstil).

    • Es definiert eine einheitliche Schnittstelle (Protokoll).
    • Es ordnet URLs Ressourcen (und nicht Operationen) zu.
    • Er sendet Nachrichten mit beliebigen MIME-Typen (statt nur SOAP + XML).
    • Es hat eine zustandslose Kommunikation und kann daher keinen serverseitigen Sitzungsspeicher haben. (SOAP hat keine Einschränkung diesbezüglich)
    • Es dient Hypermedia und die Clients verwenden Links, die Hypermedia enthalten, um den Dienst anzufordern. (SOAP RPC verwendet in der WSDL-Datei beschriebene Vorgangsbindungen)
    • Es ändert sich nicht durch URL-Änderungen nur durch semantische Änderungen. (SOAP-RPC-Clients, die keine RDF-Semantik verwenden, werden durch WSDL-Dateiänderungen unterbrochen.)
    • Es skaliert besser als ein SOAP-Webservice aufgrund seines zustandslosen Verhaltens.

    und so weiter…

    Ein SOAP RPC-Webservice erfüllt nicht alle REST-Einschränkungen:

    • Client-Server-Architektur – immer
    • staatenlos – möglich
    • Cache – möglich
    • einheitliche Schnittstelle – nie
    • geschichtetes System – niemals
    • Code auf Anfrage (optional) – möglich

    Nun, ich werde mit der zweiten Frage beginnen: Was sind Web Services? , aus offensichtlichen Gründen.

    WebServices sind im Wesentlichen Teile der Logik (die Sie vage als Methode bezeichnen können), die bestimmte functionen oder Daten offen legen. Der Client, der das Programm implementiert (technisch gesprochen, konsumierend ist das Wort), muss nur wissen, welche Parameter die Methode akzeptieren wird und welche Art von Daten es zurückgeben wird (falls überhaupt).

    Der folgende Link sagt alles über REST & SOAP in einer sehr klaren Art und Weise.

    REST vs SOAP

    Wenn Sie auch wissen möchten, wann Sie wählen sollen (REST oder SOAP), ist der Grund mehr, es zu durchlaufen!

    SOAP und REST beziehen sich beide auf Möglichkeiten für unterschiedliche Systeme, miteinander zu sprechen.

    REST verwendet dabei Techniken, die der Kommunikation ähneln, die Ihr Browser mit Webservern hat: GET, um eine Webseite anzufordern, POST in Formularfeldern usw.

    SOAP bietet etwas Ähnliches, tut aber alles durch das Senden von XML-Blöcken hin und her. Eine weitere Schlüsselkomponente von SOAP ist WSDL, ein XML-Dokument, das beschreibt, welche functionen und Datenelemente unterstützt werden. WSDLs können verwendet werden, um programmatisch zu “entdecken”, welche functionen unterstützt werden, sowie um Programmcode-Stubs zu erzeugen.

    Ich denke, das ist so einfach wie ich es erklären kann. Bitte, jeder ist willkommen, mich zu korrigieren oder hinzuzufügen.

    SOAP ist ein Nachrichtenformat, das von getrennten Systemen (wie im Internet) zum Austausch von Informationen / Daten verwendet wird. Es macht mit XML-Nachrichten hin und her.

    Web-Services senden oder empfangen SOAP-Nachrichten. Sie arbeiten unterschiedlich, je nachdem, in welcher Sprache sie geschrieben sind.

    Das Problem mit SOAP besteht darin, dass es mit den Idealen hinter dem HTTP-Stack in Konflikt steht. Jede Middleware sollte in der Lage sein, mit HTTP-Anfragen zu arbeiten, ohne den Inhalt der Anfrage oder Antwort zu verstehen. Ein regulärer HTTP-Caching-Server funktioniert jedoch nicht mit SOAP-Anfragen, ohne zu wissen, welche Teile des SOAP-Inhalts für das Caching wichtig sind. SOAP verwendet HTTP einfach als Wrapper für sein eigenes Kommunikationsprotokoll, wie einen Proxy.

    REST ist ein Architekturstil zum Entcasting von vernetzten Anwendungen. Die Idee dahinter ist, dass für die Verbindung zwischen Maschinen keine komplexen Mechanismen wie CORBA, RPC oder SOAP verwendet werden, sondern einfaches HTTP, um Anrufe zwischen Rechnern zu tätigen.

    SOAP – “Einfaches Objektzugriffsprotokoll”

    SOAP ist eine geringfügige Übertragung von Nachrichten oder kleinen Mengen von Informationen über das Internet. SOAP- Nachrichten sind in XML formatiert und werden in der Regel über HTTP gesendet.

    REST – “Repräsentativer Staatstransfer”

    REST ist ein rudimentäres Verfahren der Eventualität und empfängt Informationen zwischen Fan und Server und es sind nicht eindeutig viele Standards definiert. Sie können Informationen als JSON , XML oder sogar als einfachen Text senden und akzeptieren. Es ist leicht im Vergleich zu SOAP .

    SOAP-basierte Web-Services Kurz gesagt, das SOAP-basierte Services-Modell betrachtet die Welt als ein Ökosystem von Gleichaltrigen, die sich nicht gegenseitig kontrollieren können, sondern durch die Einhaltung veröffentlichter Verträge zusammenarbeiten müssen. Es ist ein gültiges Modell der unordentlichen realen Welt, und die metadatenbasierten Verträge bilden das SOAP Service Interface.

    Wir können SOAP weiterhin mit XML-basierten Remoteprozeduraufrufen verknüpfen, aber die SOAP-basierte Webdiensttechnologie hat sich zu einem flexiblen und leistungsstarken Messagingmodell entwickelt.

    SOAP geht davon aus, dass alle Systeme unabhängig sind und dass kein System die Interna einer anderen und internen functionalität kennt. Die meisten solcher Systeme können Nachrichten an andere senden und hoffen, dass sie darauf reagieren. Systeme veröffentlichen Verträge, die sie übernehmen, und andere Systeme verlassen sich auf diese Verträge, um Nachrichten mit ihnen auszutauschen.

    Verträge zwischen Systemen werden kollektiv als Metadaten bezeichnet und umfassen Dienstbeschreibungen, die unterstützten Nachrichtenaustauschmuster und die Richtlinien, die Dienstqualitäten regeln (ein Dienst muss möglicherweise verschlüsselt, zuverlässig geliefert werden usw.). Eine Dienstbeschreibung wiederum ist detailliert Spezifikation der Daten (Nachrichtendokumente), die vom System gesendet und empfangen werden. Die Dokumente werden mithilfe einer XML-Beschreibungssprache wie XML Schema Definition beschrieben. Solange alle Systeme ihre veröffentlichten Verträge einhalten, können sie interagieren, und Änderungen an den Interna von Systemen beeinflussen niemals andere. Jedes System ist dafür verantwortlich, seine eigenen internen Implementierungen in und aus seinen Verträgen zu übersetzen

    REST – Representative State Transfer. Das physische Protokoll ist HTTP. Grundsätzlich bedeutet REST, dass alle eindeutigen Ressourcen im Web durch eine URL eindeutig identifizierbar sind. Alle Operationen, die für diese Ressourcen ausgeführt werden können, können durch eine begrenzte Anzahl von Verben (die “CRUD” -Verben) beschrieben werden, die wiederum HTTP-Verben zugeordnet werden.

    RESTs sind viel weniger “Schwergewicht” als SOAP.

    Arbeiten von Web-Service