Warum brauchen wir RESTful Web Services?

Ich werde RESTful-Webdienste lernen (es ist besser zu sagen, dass ich dies tun muss, da es Teil des CS-Masterstudiengangs ist).

Ich habe einige Informationen in Wikipedia gelesen und auch einen Artikel über REST im Sun Developer Network gelesen. Ich sehe, dass dies keine einfache Technologie ist, dass es spezielle Frameworks zum Erstellen von RESTful-Apps gibt und dass diese häufig mit SOAP-Webdiensten und verglichen werden Programmierer sollten verstehen, wann SOAP zu verwenden ist und wann REST ein guter Ansatz sein könnte.

Ich erinnere mich, dass SOAP vor einigen Jahren sehr beliebt war (modisch?) Und der Artikel 'SOAP' in jedem guten Lebenslauf vorhanden sein musste. In der Praxis wurde es jedoch sehr selten und zu sehr einfachen Zwecken eingesetzt.

Es scheint mir, dass REST ein weiteres „letztes Wort der Mode“ ist (oder ich kann mich völlig irren, weil ich REST in der Praxis noch nie gesehen habe).

Können Sie mir einige Beispiele geben, wo REST verwendet werden sollte und warum wir ohne REST nicht dasselbe tun können (oder warum wir viel mehr Zeit damit verbringen sollten, dasselbe ohne REST zu tun)?

UPD : Leider kann ich keine konkreten Argumente sehen, die mich in den ersten Kommentaren umhauen könnten. Lassen Sie mich denken, dass REST eine großartige Technologie ist!

Ich würde gerne solche Antworten sehen:

Ich habe eine weitere komplexe HelloWorld-Anwendung entwickelt und wir müssen viele / winzige Daten übertragen. Ich habe meinem Kollegen eine REST-Lösung vorgeschlagen:

- Verdammt! Jonny, wir sollten auf jeden Fall REST für die Implementierung dieser App verwenden!
- Ja, Billy, wir können REST verwenden, aber wir sollten besser SOAP verwenden. Vertrauen Sie mir, denn ich weiß etwas über die Entwicklung von HelloWorld-Anwendungen.
- Aber SOAP ist eine altmodische Technologie aus dem letzten Jahrhundert, und wir können eine bessere verwenden.
- Billy, bist du bereit, 3 Tage damit zu verbringen, mit REST zu experimentieren? Wir können dies mit SOAP in 2 Stunden tun.
- Ja, ich bin sicher, dass wir noch mehr Zeit darauf verwenden werden, die gleiche Sicherheit / Leistung / / Skalierbarkeit / was auch immer mit SOAP zu erreichen. Ich bin sicher, dass HelloWorld-Anwendungen ab sofort nur noch mit REST entwickelt werden sollten.

REST sollte verwendet werden, wenn es für Sie sehr wichtig ist , die Kopplung zwischen Client- und Serverkomponenten in einer verteilten Anwendung zu minimieren .

Dies kann der Fall sein, wenn Ihr Server von vielen verschiedenen Clients verwendet wird , über die Sie keine Kontrolle haben. Dies kann auch der Fall sein, wenn Sie den Server regelmäßig aktualisieren möchten, ohne die Client-Software aktualisieren zu müssen.

Ich kann Ihnen versichern, dass es nicht einfach ist, dieses niedrige Kopplungsniveau zu erreichen . Es ist wichtig, alle Einschränkungen von REST zu befolgen, um erfolgreich zu sein. Die Aufrechterhaltung einer rein zustandslosen Verbindung ist schwierig. Es ist schwierig, die richtigen Medientypen auszuwählen und Ihre Daten in die Formate zu komprimieren. Das Erstellen eigener Medientypen kann noch schwieriger sein.

Das Anpassen des Rich-Server-Verhaltens an die einheitliche HTTP-Schnittstelle kann verwirrend sein und erscheint im Vergleich zum relativ einfachen RPC-Ansatz manchmal umständlich.

Trotz der Schwierigkeiten besteht der Vorteil darin, dass Sie einen Dienst haben, den ein Cliententwickler aufgrund der konsequenten Verwendung des HTTP-Protokolls leicht verstehen sollte. Der Dienst sollte aufgrund von Hypermedia leicht erkennbar sein und der Client sollte äußerst widerstandsfähig gegenüber Änderungen auf dem Server sein .

Die Vorteile von Hypermedia und die Vermeidung des Sitzungsstatus machen den Lastausgleich einfach und die Dienstpartitionierung möglich . Die strikte Einhaltung der HTTP-Regeln macht die Verfügbarkeit von Tools wie Debuggern und Caching-Proxys zu einer wunderbaren Sache.

Aktualisieren

Es scheint mir, dass REST ein weiteres „letztes Wort der Mode“ ist (oder ich kann mich völlig irren, weil ich REST in der Praxis noch nie gesehen habe).

Ich denke, REST ist in Mode gekommen, weil Leute, die versuchen, SOA-Projekte durchzuführen, festgestellt haben, dass sie mit dem SOAP-Stack die versprochenen Vorteile nicht realisieren. Als Beispiel für einfache Integrationsmethoden wenden sich die Menschen immer wieder dem Web zu. Leider denke ich, dass die Leute den Planungsaufwand und die Voraussicht, die für die Erstellung des Webs aufgewendet wurden, unterschätzen und vereinfachen, was zu tun ist, um die Art der zufälligen Wiederverwendung im Web zu ermöglichen.

Sie sagen, dass Sie REST in der Praxis noch nie gesehen haben, aber das kann unmöglich wahr sein, wenn Sie jemals einen Webbrowser verwenden. Der Webbrowser ist ein REST-Client.

• Warum müssen Sie kein Browser-Update durchführen, wenn jemand HTML auf einer Website ändert?
• Warum kann ich einer Website einen vollständigen neuen Satz von Seiten hinzufügen und der "Client" kann weiterhin ohne Aktualisierung auf diese neuen Seiten zugreifen?
• Warum muss ich dem Webbrowser keine "Service-Beschreibungssprache" bereitstellen, um ihm mitzuteilen, wenn er zu http://example.org/images/cat geht, dass der Rückgabetyp ein JPEG-Bild ist und wenn Sie gehen zu http://example.org/description/cat lautet der Rückgabetyp text / html?
• Warum kann ich einen Webbrowser verwenden, um Websites zu besuchen, die zum Zeitpunkt der Veröffentlichung des Browsers noch nicht vorhanden waren? Wie kann der Kunde über diese Websites Bescheid wissen?

Dies mag nach verrückten Fragen klingen, aber wenn Sie die Antwort kennen, können Sie sehen, worum es bei REST geht. Weitere Vorteile von REST finden Sie in StackOverflow. Wenn ich eine Frage betrachte, kann ich diese Seite mit einem Lesezeichen versehen oder die URL an einen Freund senden, und er kann dieselben Informationen sehen. Er muss nicht durch die Site navigieren, um diese Frage zu finden.

StackOverflow verwendet eine Vielzahl von OpenId-Diensten zur Authentifizierung, gravatar.com für Avatar-Bilder, Google Analytics und Quantserve für analytische Informationen. Diese Art der Integration mehrerer Unternehmen ist das, wovon die SOAP-Welt nur träumt . Eines der besten Beispiele ist die Tatsache, dass die jQuery-Bibliotheken, mit denen die StackOverflow-Benutzeroberfläche gesteuert wird, aus dem Content Delivery Network von Google abgerufen werden. Die Tatsache, dass SO den Client (dh Ihren Webbrowser) anweisen könnte, Code von einer Website eines Drittanbieters herunterzuladen, um die Leistung zu verbessern, ist ein Beweis für die geringe Kopplung zwischen Webclient und Server.

Dies sind Beispiele für eine REST-Architektur bei der Arbeit.

Jetzt verstoßen einige Websites / Anwendungen gegen die REST-Regeln, und der Browser funktioniert nicht wie erwartet.

• Das berüchtigte Problem mit der Zurück-Schaltfläche wird durch die Verwendung des serverseitigen Sitzungsstatus verursacht.
• Der Lastausgleich kann zu einem Problem werden, wenn Sie den serverseitigen Sitzungsstatus haben.
• Flash-Anwendungen verhindern häufig, dass die URL eine Darstellung spezifisch identifiziert.
• Das andere Problem, das Webbrowser beschädigt, ist die schlechte Konformität mit den Standards für Medientypen. Wir hören die ganze Zeit darüber, wie IE6 getötet werden muss. Das Problem dort ist, dass Standards nicht richtig befolgt oder aus irgendeinem Grund ignoriert wurden.
• Die Verwendung von Anmeldesitzungen ist die Quelle vieler Sicherheitslücken.

REST ist überall. Es ist der Teil des Webs, der dafür sorgt, dass es gut funktioniert. Wenn Sie verteilte Anwendungen erstellen möchten, die sich wie das Web skalieren lassen, sich wie das Web ändern und die Wiederverwendung fördern können, wie es das Web getan hat, befolgen Sie dieselben Regeln wie beim Erstellen von Webbrowsern.

REST wurde meines Wissens von Roy Fieldings Dissertation Architectural Styles und dem Design netzwerkbasierter Softwarearchitekturen ins Leben gerufen , die eine Lektüre wert ist, wenn Sie sie sich nicht angesehen haben.

Am Anfang der Dissertation steht ein Zitat:

Fast jeder fühlt sich in Frieden mit der Natur: Lauschen Sie den Meereswellen gegen das Ufer, an einem stillen See, auf einem Grasfeld, auf einer vom Wind verwehten Heide. Eines Tages, wenn wir den zeitlosen Weg wieder gelernt haben, werden wir uns in unseren Städten genauso fühlen, und wir werden uns in ihnen genauso wohl fühlen wie heute, wenn wir am Meer spazieren gehen oder uns im langen Gras eines Menschen ausstrecken Wiese.

- Christopher Alexander, Die zeitlose Bauweise (1979)

Und das fasst es dort wirklich zusammen. REST ist in vielerlei Hinsicht eleganter.

SOAP ist ein Protokoll über HTTP, das viele HTTP-Konventionen zum Erstellen neuer Konventionen in SOAP umgeht und in vielerlei Hinsicht mit HTTP redundant ist. HTTP ist jedoch mehr als ausreichend, um Informationen über HTTP abzurufen, zu suchen, zu schreiben und zu löschen, und genau das ist REST. Da REST nicht darüber, sondern mit HTTP erstellt wird, bedeutet dies auch, dass Software, die in REST integriert werden möchte (z. B. ein Webbrowser), SOAP nicht verstehen muss, sondern nur HTTP, das am meisten sein muss weit verbreitetes und in das derzeit verwendete Protokoll integriert.

Von hier aus :

REST Vorteile:

• Leichtgewichtler - nicht viel zusätzliches XML-Markup
• Vom Menschen lesbare Ergebnisse
• Einfach zu bauen - keine Toolkits erforderlich

Überprüfen Sie auch dieses aus:

Um fair zu sein, ist REST nicht die beste Lösung für jeden Webdienst. Daten, die sicher sein müssen, sollten nicht als Parameter in URIs gesendet werden. Und große Datenmengen, wie sie in detaillierten Bestellungen enthalten sind, können innerhalb einer URI schnell umständlich oder sogar außerhalb der Grenzen liegen. In diesen Fällen ist SOAP in der Tat eine feste Lösung. Es ist jedoch wichtig, zuerst REST zu versuchen und nur bei Bedarf auf SOAP zurückzugreifen. Dies hilft, die Anwendungsentwicklung einfach und zugänglich zu halten.

Ich kann mit Sicherheit sagen, dass ich als Anfänger viel Zeit damit verbracht habe, dies zu verstehen, aber dies ist der beste Link, um mit REST von Grund auf neu zu beginnen! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Nur um dich reinzuziehen,

Überlegen Sie, was ein "traditioneller Webdienst" ist. Es ist eine Schnittstelle mit exponierten "Methoden". Clients kennen den Namen, die Eingabe und die Ausgabe der Methoden und können sie daher aufrufen.

Stellen Sie sich nun eine Schnittstelle vor, die keine "Methoden" verfügbar macht. Stattdessen werden "Objekte" verfügbar gemacht. Wenn ein Client diese Schnittstelle sieht, sieht er nur ein oder mehrere "Objekte". "Ein Objekt" hat keine Ein- und Ausgabe - weil "es nichts tut". Es ist ein Substantiv, kein Verb. Es ist "eine Sache", keine "Handlung".

Stellen Sie sich beispielsweise einen traditionellen Webdienst vor, der die aktuellen Wetterbedingungen bereitstellt, wenn Sie ihm eine Stadt zur Verfügung stellen. Es hat wahrscheinlich eine Webmethode wie GetWeatherInfo (), die eine Stadt als Eingabe verwendet und Wetterdaten als Ausgabe bereitstellt. Bisher ist es für Sie leicht zu verstehen, wie ein Client diesen Webdienst nutzt.

Stellen Sie sich nun vor, anstelle des oben genannten Webdienstes gibt es einen neuen, der Städte als Objekte verfügbar macht. Wenn Sie es also als Client betrachten, sehen Sie anstelle von GetWeatherInfo () New York, Dallas, Los Angeles, London und so weiter. Und an diesen Städten hängen keine anwendungsspezifischen Methoden - sie sind anscheinend wie Inertgase - sie selbst reagieren nicht.

Sie müssen nachdenken - wie hilft Ihnen das als Kunde, an das Wetter in Dallas heranzukommen? Wir werden in wenigen Augenblicken darauf zurückkommen.

Wenn alles, was Sie von einem Webdienst erhalten, eine "Menge von Objekten" ist, brauchen Sie offensichtlich eine Möglichkeit, "auf sie zu reagieren". Die Objekte selbst haben keine Methoden zum Aufrufen, daher benötigen Sie eine Reihe von Aktionen, die Sie auf diese Objekte anwenden können. Mit anderen Worten, Sie müssen "ein Verb auf das Substantiv anwenden". Wenn Sie ein Objekt sehen, beispielsweise einen Apfel, der "ein Substantiv" ist, können Sie "ein Verb" wie "Essen" darauf anwenden. Es können jedoch nicht alle Verben auf alle Substantive angewendet werden. Sie können ein Auto fahren, aber keinen Fernseher.

Wenn also ein Webdienst nur Objekte verfügbar macht und Sie gefragt werden, lassen Sie uns nun einige Standardaktionen oder -verben entwerfen, die "alle Clients auf alle Objekte anwenden können, die sie sehen", ...

Hier sind ein paar Ideen:

• REST beschränkt Ihren Service auf die Verwendung einer einheitlichen Schnittstelle. Sie müssen keine Zeit damit verschwenden, über alle möglichen Funktionsweisen Ihres Dienstes zu träumen (oder zu streiten) - Sie können sofort die Ressourcen in Ihrem System identifizieren. Es stellt sich als große Aufgabe heraus, aber glücklicherweise sind die Probleme viel besser definiert.
• Mit den Ressourcen, ihren Assoziationen und ihren Darstellungen in der Hand gibt es wirklich sehr wenig zu tun, um Ihren Service zu implementieren, da viele Entscheidungen für Sie getroffen wurden.
• Ihr System sieht anderen RESTful-Systemen sehr ähnlich. Lernkurven für Teamkollegen, Partner und Kunden werden reduziert.
• Sie haben ein gemeinsames Vokabular, um Designprobleme mit anderen Entwicklern und sogar mit weniger technisch denkenden Personen (z. B. Kunden) zu besprechen.
• Wie Darrel sagt, beschränkt Ihr Service den Umfang der Kopplung auf nur eine Sache - Medientypen , da Sie ein hypertextgesteuertes Design verwenden. Dies hilft Ihnen als Entwickler, da Änderungen an Ihrem System in einem engen Kontaktbereich enthalten sind. Dies hilft Ihren Kunden dabei, dass weniger Änderungen ihren Code beschädigen.
• Fast jedes Problem bei der Implementierung von REST kann gelöst werden, indem Sie eine neue Ressource verfügbar machen oder Ihr Ressourcenmodell überdenken. Dieser Fokus ist, IMO, ein großer Produktivitätsschub.

Unter dem Strich entfernt REST viele der zeitaufwändigsten und umstrittensten Entwurfs- und Implementierungsentscheidungen aus dem Workflow Ihres Teams. Es lenkt Ihre Aufmerksamkeit von der Implementierung Ihres Dienstes auf die Gestaltung . Und das ohne Gobbledygook auf das HTTP-Protokoll zu stapeln.

Die meisten "Pro" -Antworten zu REST scheinen von Personen zu stammen, die noch nie einen SOAP-Webdienst oder -Client in einer Umgebung entwickelt haben, die geeignete Tools für die Aufgabe bereitstellt. Sie beschweren sich über Probleme, auf die ich mit Visual Studio .NET und IBMs Rational Web Developer einfach nie gestoßen bin. Ich nehme an, wenn Sie Webdienste oder Clients in einer Skriptsprache oder einer anderen Sprache mit wenig oder keiner Toolunterstützung entwickeln müssen, handelt es sich um gültige Beschwerden.

Ich muss auch zugeben, dass einige der "Pro" -Punkte wie Dinge klingen, die tatsächlich wahr sein könnten - aber dass ich noch nie ein Beispiel gesehen habe, das ihren Wert veranschaulicht. Insbesondere würde ich es sehr begrüßen, wenn jemand einen Kommentar mit einem Link zu einem guten Beispiel eines REST-Webdienstes veröffentlichen würde. Dies sollte eine sein, die mehrere Ressourcenebenen verwendet, möglicherweise in einer Hierarchie, und die Medientypen ordnungsgemäß verwendet. Wenn ich mir ein gutes Beispiel anschaue, verstehe ich vielleicht, in welchem ​​Fall ich hierher zurückkomme und es zugebe.

Um den Antworten einen etwas prosaischen Touch zu verleihen, verwenden wir REST-Services, wenn ich weiß, dass Sie einem Geschäftspartner eine URL geben können und wissen, dass er im Gegenzug eine übersichtliche XML-Platte erhält Egal, ob sie in .Net xx, PHP, Python, Java, Ruby oder Gott-weiß-was arbeiten, es reduziert Kopfschmerzen erheblich.

Dies bedeutet auch, dass unsere Vertriebsmitarbeiter auf nicht-technischer Ebene mit unserer vielseitigen API prahlen können, ohne befürchten zu müssen, wie komplette Muppets auszusehen.

Abgesehen von den technischen Vorteilen ist es für Nicht-Techniker eine gute Sache, etwas zu erklären, zu demonstrieren und sich sicher zu fühlen. SOAP ist zwar für Technikfreaks genauso cool, für Nicht-Technikfreaks jedoch weitaus weniger zugänglich und daher nicht so einfach zu "verkaufen".

Ich neige dazu zu bemerken, dass Dinge, die Nicht-Technikfreaks den Kopf verdrehen können, dazu neigen, zu bleiben. Daher bezweifle ich, dass REST als Technik für die Launen der Mode genauso anfällig ist wie SOAP.

Aber all das Zeug, nichts in einen REST-Service zu stecken, das gesperrt werden sollte, ist doppelt wahr, schon allein deshalb, weil die Technologie für Leute, die nicht so technisch denken, so leicht zu verstehen ist.

REST ist ein Architekturstil zum Entwerfen von Netzwerkanwendungen. Die Idee ist, dass anstelle komplexer Mechanismen wie CORBA, RPC oder SOAP für die Verbindung zwischen Computern einfaches HTTP verwendet wird, um Anrufe zwischen Computern zu tätigen.

In vielerlei Hinsicht kann das auf HTTP basierende World Wide Web selbst als REST-basierte Architektur angesehen werden. RESTful-Anwendungen verwenden HTTP-Anforderungen, um Daten zu veröffentlichen (zu erstellen und / oder zu aktualisieren), Daten zu lesen (z. B. Abfragen zu stellen) und Daten zu löschen. Daher verwendet REST HTTP für alle vier CRUD-Vorgänge (Erstellen / Lesen / Aktualisieren / Löschen).

REST ist eine einfache Alternative zu Mechanismen wie RPC (Remote Procedure Calls) und Web Services (SOAP, WSDL, et al.). Später werden wir sehen, wie viel einfacher REST ist.

Obwohl REST einfach ist, bietet es alle Funktionen. Grundsätzlich können Sie in Web Services nichts tun, was mit einer RESTful-Architektur nicht möglich ist. REST ist kein "Standard". Es wird zum Beispiel niemals eine W3C-Empfehlung für REST geben. Und obwohl es REST-Programmierframeworks gibt, ist die Arbeit mit REST so einfach, dass Sie häufig mit Standardbibliotheksfunktionen in Sprachen wie Perl, Java oder C # "Ihre eigenen rollen" können.