Sollte ein Webdienst im Netflix- oder Twitter-Stil REST oder SOAP verwenden? [geschlossen]

Ich habe zwei REST-Dienste implementiert: Twitter und Netflix. Beide Male hatte ich Mühe, die Verwendung und Logik der Entscheidung zu finden, diese Dienste als REST anstelle von SOAP bereitzustellen. Ich hoffe, jemand kann mich auf das hinweisen, was mir fehlt, und erklären, warum REST als Service-Implementierung für Services wie diese verwendet wurde.

1. Die Implementierung eines REST-Service dauert unendlich länger als die Implementierung eines SOAP-Service. Es gibt Tools für alle modernen Sprachen / Frameworks / Plattformen, um eine WSDL einzulesen und Proxy-Klassen und Clients auszugeben. Die Implementierung eines REST-Service erfolgt von Hand und - erhalten Sie dies - durch Lesen der Dokumentation. Darüber hinaus müssen Sie bei der Implementierung dieser beiden Dienste "Vermutungen" anstellen, was über die Pipe zurückkommt, da es kein echtes Schema oder Referenzdokument gibt.

2. Warum einen REST-Service schreiben, der trotzdem XML zurückgibt? Der einzige Unterschied besteht darin, dass Sie mit REST nicht wissen, welche Typen jedes Element / Attribut darstellt. Sie müssen es selbst implementieren und hoffen, dass eines Tages eine Zeichenfolge nicht in einem Feld vorkommt, von dem Sie dachten, es sei immer ein int. SOAP definiert die Datenstruktur mithilfe der WSDL, sodass dies ein Kinderspiel ist.

3. Ich habe die Beschwerde gehört, dass Sie mit SOAP den "Overhead" des SOAP-Umschlags haben. Müssen wir uns heutzutage wirklich um eine Handvoll Bytes sorgen?

4. Ich habe das Argument gehört, dass Sie mit REST einfach die URL in den Browser einfügen und die Daten anzeigen können. Sicher, wenn Ihr REST-Service eine einfache oder keine Authentifizierung verwendet. Der Netflix-Dienst verwendet beispielsweise OAuth, bei dem Sie Dinge signieren und verschlüsseln müssen, bevor Sie Ihre Anfrage überhaupt senden können.

5. Warum benötigen wir für jede Ressource eine "lesbare" URL? Wenn wir ein Tool zur Implementierung des Dienstes verwendet haben, ist uns dann die tatsächliche URL wirklich wichtig?

Ein Kanarienvogel in einer Kohlenmine.

Ich habe seit fast einem Jahr auf eine solche Frage gewartet. Es war unvermeidlich, dass dieser Tag kommen würde, und ich bin sicher, dass wir in den kommenden Monaten noch viele weitere Fragen wie diese sehen werden.

Die Warnschilder

Sie haben absolut Recht, das Erstellen von RESTful-Clients dauert länger als das Erstellen von SOAP-Clients. Die SOAP-Toolkits entfernen viel Code und stellen Client-Proxy-Objekte fast mühelos zur Verfügung. Mit einem Tool wie Visual Studio und einer Server-URL kann ich in weniger als fünf Minuten lokal auf Remote-Objekte beliebiger Komplexität zugreifen.

Dienste, die application / xml und application / json zurückgeben, sind für Cliententwickler so ärgerlich. Was sollen wir mit diesem Datenklumpen machen?

Glücklicherweise bieten viele Websites, die REST-Services bereitstellen, auch eine Reihe von Client-Bibliotheken, sodass wir diese Bibliotheken verwenden können, um Zugriff auf eine Reihe stark typisierter Objekte zu erhalten. Scheint irgendwie dumm zu sein. Wenn sie SOAP verwendet hätten, hätten wir diese Proxy-Klassen selbst mit Code generieren können.

Seifenkopf, ha. Es ist die Latenz, die tötet. Wenn die Leute wirklich besorgt sind über die Anzahl der überschüssigen Bytes, die über das Kabel gehen, ist HTTP möglicherweise nicht die richtige Wahl. Haben Sie gesehen, wie viele Bytes vom User-Agent-Header verwendet werden?

Ja, haben Sie jemals versucht, einen Webbrowser als Debugging-Tool für etwas anderes als HTML und Javascript zu verwenden? Vertrau mir, es ist scheiße. Sie können nur zwei der Verben verwenden, das Caching stört ständig, die Fehlerbehandlung verschluckt so viele Informationen, dass ständig nach einem gottverdammten favicon.ico gesucht wird. Erschieß mich einfach.

Lesbare URL. Nur Substantive, keine Verben. Ja, das ist einfach, solange wir nur CRUD-Operationen ausführen und nur auf eine Weise auf eine Hierarchie von Objekten zugreifen müssen. Leider benötigen die meisten Anwendungen etwas mehr Funktionalität.

Die bevorstehende Katastrophe

Derzeit gibt es eine große Anzahl von Entwicklern, die Anwendungen entwickeln, die in REST-Services integriert sind und dabei sind, zu denselben Schlussfolgerungen zu gelangen, die Sie haben. Ihnen wurde Einfachheit, Flexibilität, Skalierbarkeit, Evolvabilität und der heilige Gral der zufälligen Wiederverwendung versprochen. Die Eigenschaften des Webs selbst, wie kann etwas schief gehen.

Sie stellen jedoch fest, dass die Versionierung genauso problematisch ist, aber der Compiler hilft nicht, Probleme zu erkennen. Der handgeschriebene Client-Code ist schwierig zu pflegen, wenn sich die Datenstrukturen weiterentwickeln und URLs überarbeitet werden. Das Entwerfen von APIs nur für Substantive und vier Verben kann sehr schwierig sein, insbesondere wenn RESTful Url-Fanatiker Ihnen mitteilen, wann Sie Abfragezeichenfolgen verwenden können und wann nicht.

Entwickler werden sich fragen, warum wir unsere Anstrengungen für die Unterstützung von Json- und XML-Formaten verschwenden. Warum konzentrieren wir uns nicht einfach auf eines und machen es gut?

Wie ist es so schief gegangen?

Ich werde dir sagen, was schief gelaufen ist. Wir als Entwickler lassen die Marketingabteilungen unsere Hauptschwäche ausnutzen. Unsere ewige Suche nach der Silberkugel machte uns blind für die Realität dessen, was REST wirklich ist. An der Oberfläche scheint REST so einfach und unkompliziert zu sein. Benennen Sie Ihre Ressourcen mit Urls und verwenden Sie GET, PUT, POST und DELETE. Zur Hölle, wir Entwickler wissen bereits, wie das geht. Wir beschäftigen uns seit Jahren mit Datenbanken mit Tabellen und Spalten und SQL-Anweisungen mit SELECT, INSERT, UPDATE und DELETE. Es hätte ein Kinderspiel sein sollen.

Es gibt andere Teile von REST, die einige Leute diskutieren, wie die Selbstbeschreibung und die Hypermedia-Einschränkung, aber diese Einschränkungen sind nicht so einfach wie die Ressourcenidentifikation und die einheitliche Schnittstelle. Das scheint die Komplexität zu erhöhen, wenn das gewünschte Ziel die Einfachheit ist.

Diese verwässerte Version von REST wurde in vielerlei Hinsicht in der Entwicklerkultur validiert. Es wurden Server-Frameworks erstellt, die die Ressourcenidentifizierung und die einheitliche Benutzeroberfläche fördern, die anderen Einschränkungen jedoch nicht unterstützen. Die Begriffe schwebten herum und unterschieden die Ansätze (HI-REST gegen LO-REST, Corporate REST gegen Academic REST, REST gegen RESTful).

Ein paar Leute schreien, dass es nicht REST ist, wenn Sie nicht alle Einschränkungen anwenden. Sie werden die Vorteile nicht erhalten. Es gibt keine halbe Ruhe. Aber diese Stimmen wurden als religiöse Eiferer bezeichnet, die sich darüber aufregten, dass ihre kostbare Bezeichnung aus der Dunkelheit gestohlen und zum Mainstream gemacht worden war. Eifersüchtige Menschen, die versuchen, REST schwieriger klingen zu lassen als es ist.

Der Begriff REST ist definitiv zum Mainstream geworden. Fast jede wichtige Web-Eigenschaft, die eine API hat, unterstützt "REST". Twitter und Netflix sind zwei sehr bekannte. Die beängstigende Sache ist, dass ich nur an eine öffentliche API denken kann, die selbstbeschreibend ist, und es gibt eine Handvoll, die die Hypermedia-Einschränkung wirklich implementieren. Sicher, einige Websites wie StackOverflow und Gowalla unterstützen Links in ihren Antworten, aber es gibt große Lücken in ihren Links. Die StackOverflow-API hat keine Stammseite. Stellen Sie sich vor, wie erfolgreich die Website gewesen wäre, wenn es keine Homepage für die Website gegeben hätte!

Sie wurden irregeführt, fürchte ich

Wenn Sie es bis hierher geschafft haben, lautet die kurze Antwort auf Ihre Frage, dass diese APIs (Netflix und Twitter) nicht allen Einschränkungen entsprechen und Sie daher nicht die Vorteile erhalten, die REST-APIs bieten sollen.

Die Erstellung von REST-Clients dauert länger als bei SOAP-Clients, sie sind jedoch nicht an einen bestimmten Service gebunden. Sie sollten sie daher dienstübergreifend wiederverwenden können. Nehmen Sie das klassische Beispiel eines Webbrowsers. Auf wie viele Dienste kann ein Webbrowser zugreifen? Was ist mit einem Feed Reader? Auf wie viele verschiedene Dienste kann der durchschnittliche Twitter-Client zugreifen? Ja, nur eine.

REST-Clients sollten nicht für die Schnittstelle mit einem einzelnen Dienst erstellt werden, sondern für die Verarbeitung bestimmter Medientypen, die von jedem Dienst bereitgestellt werden können. Die offensichtliche Frage dazu ist, wie Sie einen REST-Client für einen Dienst erstellen können, der application / json oder application / xml bereitstellt. Das kannst du nicht. Dies liegt daran, dass diese Formate für einen REST-Client völlig nutzlos sind. Du hast es selbst gesagt,

Sie müssen "raten", was über die Pipe zurückkommt, da es kein echtes Schema oder Referenzdokument gibt

Sie sind absolut korrekt für Dienste wie Twitter. Die selbstbeschreibende Einschränkung in REST besagt jedoch, dass der HTTP-Inhaltstyp-Header genau den Inhalt beschreiben sollte, der über die Leitung übertragen wird. Wenn Sie application / json und application / xml bereitstellen, erfahren Sie nichts über den Inhalt.

Wenn es um die Leistung von REST-basierten Systemen geht, muss das Gesamtbild betrachtet werden. Das Sprechen über Hüllkurvenbytes ist wie das Abwickeln von Schleifen, wenn eine schnelle Sortierung mit einer Shell-Sortierung verglichen wird. Es gibt Szenarien, in denen SOAP eine bessere Leistung erbringen kann, und es gibt Szenarien, in denen REST eine bessere Leistung erbringen kann. Der Kontext ist alles.

REST gewinnt einen großen Teil seines Leistungsvorteils, indem es sehr flexibel in Bezug auf die unterstützten Medientypen ist und eine ausgefeilte Unterstützung für das Caching bietet. Damit das Caching gut funktioniert, müssen jedoch fast alle Einschränkungen eingehalten werden.

Ihr letzter Punkt über lesbare URLs ist bei weitem der ironischste. Wenn Sie sich wirklich zur Hypermedia-Einschränkung verpflichten, könnte jede URL eine GUID sein und der Client-Entwickler würde nichts an Lesbarkeit verlieren.

Die Tatsache, dass URIs für den Client undurchsichtig sein sollten, ist eines der wichtigsten Dinge bei der Entwicklung von REST-Systemen. Lesbare URLs sind für den Serverentwickler praktisch und gut strukturierte URLs erleichtern dem Server-Framework das Versenden von Anforderungen. Dies sind jedoch Implementierungsdetails, die keinen Einfluss auf die Entwickler haben sollten, die die API verwenden.

Die Twitter-API ist nicht annähernd REST-fähig, weshalb Sie keinen Nutzen aus der Verwendung über SOAP ziehen können. Die Netflix-API ist viel näher, aber die Verwendung generischer Medientypen zeigt, dass die Nichteinhaltung einer einzigen Einschränkung einen tiefgreifenden Einfluss auf die Vorteile des Dienstes haben kann.

Es kann nicht alles ihre Schuld sein

Ich habe eine Menge Dumping auf die Dienstleister gemacht, aber es braucht zwei, um RESTfully zu tanzen. Ein Dienst kann allen Einschränkungen religiös folgen und ein Kunde kann dennoch alle Vorteile leicht rückgängig machen.

Wenn ein Client URLs fest codiert, um auf bestimmte Arten von Ressourcen zuzugreifen, verhindert dies, dass der Server diese URLs ändert. Jede Art von URL-Konstruktion, die auf implizitem Wissen darüber basiert, wie der Dienst seine URLs strukturiert, ist eine Verletzung.

Annahmen darüber, welche Art von Darstellung von einem Link zurückgegeben wird, können zu Problemen führen. Wenn Sie Annahmen über den Inhalt der Darstellung treffen, die auf Wissen basieren, das nicht explizit in den HTTP-Headern angegeben ist, wird dies definitiv zu einer Kopplung führen, die in Zukunft Schmerzen verursachen wird.

Sollten sie SOAP verwendet haben?

Persönlich denke ich nicht. REST richtig gemacht ermöglicht es einem verteilten System, sich langfristig weiterzuentwickeln. Wenn Sie verteilte Systeme mit Komponenten erstellen, die von verschiedenen Personen entwickelt wurden und viele Jahre halten müssen, ist REST eine ziemlich gute Option.

SOAP ist ein objektorientierter , Remote Procedure Call - Technologie - Stack. Es funktioniert, indem eine neue Abstraktion auf einem vorhandenen Protokoll (HTTP) aufgebaut wird.

REST ist ein dokumentenorientierter Ansatz, der einfach die Funktionen eines vorhandenen Protokolls (HTTP) verwendet. „REST“ ist nur ein Schlagwort - das Konzept ist das: einfach im Internet die Art und Weise benutzt es wurde entworfen , um Arbeit!

Als Antwort auf Änderungen an der Frage:

1. "Die Implementierung eines REST-Service dauert unendlich viel länger als die Implementierung eines SOAP-Service."

   Ähm, nein, es kann nicht unendlich lange dauern. Und in Fällen, in denen Sie versuchen, ein Dokument oder eine Datei abzurufen, ist dies tatsächlich viel schneller . Beispielsweise definiert die OGC-Spezifikation für WMS (Web Mapping Service) sowohl eine SOAP- als auch eine REST-Version des Protokolls, und es gibt einen Grund, warum fast niemand die SOAP-Version implementiert - weil Sie versuchen, eine Karte zu erhalten Es ist viel einfacher, eine URL zu erstellen und Bildbytes von dieser URL abzurufen, als sie in eine SOAP-Nachricht zu kapseln. Aber ja, ich bin damit einverstanden, dass SOAP für diese Verwendung besser geeignet ist, wenn der Zweck des Webdienstes darin besteht, ein stark typisiertes Objekt in ein Domänenobjektmodell zu übertragen.

2. "Warum einen REST-Service schreiben, der trotzdem XML zurückgibt?"

   Ja, das kann albern sein. Aber es kommt darauf an, was das XML ist. Wenn es irgendwo ein klar definiertes Schema dafür gibt, gibt es keine Mehrdeutigkeit. Sie können sich WSDL-URLs beispielsweise als eine Art RESTful-Webdienst zum Abrufen von Informationen zu einem Webdienst vorstellen. In diesem Fall wäre es sinnlos, den Overhead einer anderen SOAP-Anforderung hinzuzufügen.

   Im Allgemeinen gewinnt REST, wenn der übertragene Inhalt als Datei, als einzelne Einheit betrachtet werden kann . SOAP gewinnt, wenn der Inhalt als Objekt mit Mitgliedern behandelt werden muss .

3. "Ich habe die Beschwerde gehört, dass Sie mit SOAP den" Overhead "des SOAP-Umschlags haben. Müssen wir uns heutzutage wirklich um eine Handvoll Bytes sorgen?"

   Ja. Nicht unter allen Umständen, aber es gibt Websites mit viel Verkehr, auf denen es einen Unterschied macht. Reicht es aus, die semantischen Unterschiede bei der Verwendung von SOAP anstelle von REST aufzuwiegen? Ich bezweifle das. Wenn Sie ein Objekt-Remoting-Protokoll ausführen und die Anzahl der Bytes einen Unterschied macht, ist SOAP wahrscheinlich sowieso nicht das richtige Tool für Sie - vielleicht sollten Sie stattdessen CORBA oder DCOM verwenden.

4. "Ich habe das Argument gehört, dass Sie mit REST einfach die URL in den Browser einfügen und die Daten anzeigen können."

   Ja, und dies ist ein großes Argument für REST, wenn es sinnvoll ist, die Daten in einem Browser anzuzeigen . Mit Bilddaten ist es beispielsweise eine einfache Möglichkeit, den Dienst zu debuggen. Fügen Sie einfach die URL in die Adressleiste Ihres Browsers ein und sehen Sie, wie das Bild aussieht. Wenn die zurückgegebenen Daten in XML vorliegen und Sie über ein referenziertes XML-Stylesheet verfügen, das im Browser in lesbares HTML umgewandelt wird, profitieren Sie von semantischem Markup und einfacher Visualisierung in einem Paket. Aber Sie haben Recht, dieser Vorteil verschwindet meistens, wenn Sie mit komplexeren Authentifizierungsschemata arbeiten. Wenn Sie nicht alle Ihre Authentifizierungsinformationen in jede HTTP-Anforderung codieren können , würde ich argumentieren, dass dies überhaupt nicht als REST gilt.

5. "Warum benötigen wir für jede Ressource eine" lesbare "URL? Wenn wir ein Tool zur Implementierung des Dienstes verwendet haben, ist uns die tatsächliche URL wirklich wichtig?"

   Es hängt davon ab. Warum benötigen wir lesbare URLs für eine Ressource im Web? Sie können den Aufsatz von Tim Berners-Lee lesen. Coole URIs ändern sich nicht , aber im Grunde sollte der URI für diese Ressource gleich bleiben, solange die Ressource in Zukunft noch nützlich ist.

   Offensichtlich besteht für vorübergehende Ressourcen (wie der Link "Heutiges Geld" im Aufsatz) keine Notwendigkeit dafür, da die Notwendigkeit, auf die Ressource zu verweisen, wegfällt, wenn die entsprechende Ressource wegfällt. Für dauerhaftere Ressourcen (wie z. B. StackOverflow-Fragen oder Filme in der IMDB) möchten Sie jedoch eine URL haben, die für immer funktioniert. Wenn Sie einen Webdienst entwerfen, müssen Sie entscheiden, ob die Ressourcen selbst Ihren Dienst überleben könnten. Wenn ja, ist REST wahrscheinlich der richtige Weg.

Ja, ich habe Webseiten entwickelt, lange bevor es NetFlix oder Twitter gab. Und nein, ich hatte noch keine Notwendigkeit oder Gelegenheit, einen Client für die Dienste von NetFlix oder Twitter zu implementieren. Aber selbst wenn es äußerst schwierig ist, mit ihren Diensten zu arbeiten, bedeutet dies nicht, dass die Technologie, auf der sie ihre Dienste implementiert haben, schlecht ist - nur, dass diese beiden Implementierungen schlecht sind.

Um es kurz zu machen: REST und SOAP sind nur Werkzeuge . Sie haben jeweils Stärken und Schwächen. Wenn das einzige Werkzeug, das Sie haben, ein Hammer ist, sieht jedes Problem wie ein Nagel aus. Lernen Sie also beide Tools kennen, lernen Sie, wie Sie sie richtig verwenden, und wählen Sie dann für jeden Job das richtige Tool aus.

Eine ehrliche Frage verdient eine ehrliche Antwort. Aber zuerst, warum haben Sie den Text dieser Frage als Antwort auf eine andere Frage verwendet, wenn Sie nicht der Meinung waren, dass er rhetorischer Natur ist?

Wie auch immer:

1. "Es gibt Tools für alle modernen Sprachen / Frameworks / Plattformen zum Einlesen einer WSDL und zum Ausgeben von Proxy-Klassen und Clients. Die Implementierung eines REST-Service erfolgt manuell durch Lesen der Dokumentation. "

   Genau wie Browser-Anbieter die HTML 4.01-Spezifikation nach oben und unten gelesen und erneut gelesen haben, um zu versuchen, ein konsistentes Browser-Erlebnis zu implementieren. Haben Sie darüber nachgedacht, dass Browser lange vor dem Internet-Banking und dem Stackoverflow erfunden wurden, und dennoch können Sie einen Browser verwenden, um genau diese Dinge zu tun. Dies ist nur deshalb möglich, weil alle der Verwendung von HTML (und verwandten Formaten wie CSS, JS, JPEG usw.) zustimmen.

   Das Bloggen ist eigentlich nicht so neu, und jemand hat sich AtomPub ausgedacht, mit dem jede Blogging-Software auf Beiträge in einem Blog zugreifen und diese aktualisieren kann, ähnlich wie jeder Webbrowser auf jede Webseite zugreifen kann. Das ist ziemlich ordentlich und funktioniert aufgrund der vom Protokoll auferlegten RESTful-Einschränkungen.

   Für Twitter und Netflix gibt es jedoch keine allgemeine Vereinbarung, dass "alle existierenden Microblogs die Anwendung / den Tweet vom Medientyp verwenden sollen", hauptsächlich weil Microblogging so neu ist. Vielleicht werden in ein paar Jahren einige Microblogging-Dienste auf derselben API basieren, damit Twitter, Facebook, Identica und zusammenarbeiten können. Keine ihrer vorhandenen APIs ist in der Nähe von RESTful, wie viel sie auch behaupten, daher erwarte ich nicht, dass dies bald geschieht.

   " Außerdem müssen Sie bei der Implementierung dieser beiden Dienste" raten ", was über die Pipe zurückkommt, da es kein wirkliches Schema oder Referenzdokument gibt. "

   Du hast den Nagel auf den Kopf getroffen. Bei REST dreht sich alles um verteilte und hypermediale Medien, und das fasst es ziemlich gut zusammen. Ein Browser überprüft, was er von einer Anfrage erhält, und zeigt es dem Benutzer an. Eine HTML-Seite erzeugt normalerweise viel mehr GET-Anforderungen, zum Beispiel CSS, Skripte und Bilder. Ein Bild wird normalerweise nur auf dem Bildschirm gerendert, JavaScript wird ausgeführt und so weiter. Der Browser macht jedes Mal das, was er tut, weil er den Link in einem <img>oder <style>-Tag gefunden hat und der Antwortmedientyp image/jpegoder war text/css.

   Wenn Twitter eine hypermedienbasierte API erstellt, wird diese wahrscheinlich application/tweetjedes Mal zurückgegeben, wenn Sie einem Link zu einem Tweet folgen. Der Client sollte dies jedoch niemals annehmen und immer überprüfen, was er erhält, bevor er darauf reagiert.

2. " Warum einen REST-Service schreiben, der trotzdem XML zurückgibt? "

   Dies alles läuft auf Medientypen hinaus. Wenn Sie wie bei HTML ein Element sehen, von dem Sie keine Ahnung haben, was es tatsächlich bedeutet, werden Sie in der HTML-Spezifikation angewiesen, diese zu ignorieren und den "Body" des Tags zu verarbeiten, falls vorhanden. Ebenso weist Sie die Atomspezifikation an, unbekannte Elemente und fremde Markups (aus verschiedenen Namespaces) zu ignorieren und den Body (IIRC) nicht zu verarbeiten.

   Das Entwerfen von Medientypen für generische Problemdomänen (wie beim HTML- Medientyp für die Rich-Text- Problemdomäne) ist sehr schwierig. Das Erstellen von Medientypen für sehr enge Problemdomänen ist wahrscheinlich viel einfacher (wie ein Tweet). Es ist jedoch immer eine gute Idee, auf Erweiterbarkeit zu achten und anzugeben, wie Clients (und Server) reagieren sollen, wenn sie Elemente oder Datenelemente sehen, die nicht mit der Spezifikation übereinstimmen. JPEG verfügt beispielsweise über einen anwendungsspezifischen Datensatztyp (z. B. APP1), der alle Arten von Metadaten enthält.

3. " Ich habe die Beschwerde gehört, dass Sie mit SOAP den" Overhead "des SOAP-Umschlags haben. Müssen wir uns heutzutage wirklich um eine Handvoll Bytes sorgen? "

   Nein, das tun wir nicht. Bei REST geht es absolut nicht darum, über das Kabel effizient zu sein, sondern darum, die Effizienz des Kabels einzutauschen. Die Effizienz von REST beruht auf den Möglichkeiten des Caching, die durch alle anderen Einschränkungen ermöglicht werden: Anmerkungen zur Dissertation von Fielding : Der Nachteil besteht jedoch darin, dass sich eine einheitliche Schnittstelle verschlechtert Effizienz, da Informationen in einer standardisierten Form übertragen werden und nicht in einer Form, die auf die Bedürfnisse einer Anwendung zugeschnitten ist. Die REST-Schnittstelle ist so konzipiert, dass sie für die Übertragung von Hypermedia-Daten mit großen Körnern effizient ist und für den allgemeinen Fall des Web optimiert ist. Dies führt jedoch zu einer Schnittstelle, die für andere Formen der architektonischen Interaktion nicht optimal ist. Ich denke nicht, dass der Overhead der SOAP Envelope-Byteanzahl ein berechtigtes Anliegen ist.

4. " Ich habe das Argument gehört, dass Sie mit REST einfach die URL in den Browser einfügen und die Daten anzeigen können. "

   Ja, das ist auch ein ungültiges Argument. So funktioniert es nicht. Selbst wenn es funktioniert hat, verwenden die meisten engen REST-APIs Medientypen, von denen Browser keine Ahnung haben und die immer noch nicht funktionieren.

   Es gibt jedoch viel mehr Möglichkeiten als ein Browser, eine HTTP-basierte API zu testen, z. B. Befehlszeilenprogramme oder Browsererweiterungen, mit denen Sie nahezu jeden Aspekt einer HTTP-Anforderung steuern, Antwortheader überprüfen und Links finden können, denen Sie folgen können. Trotzdem ist dies bei weitem nicht so einfach wie das Generieren von WSDL-Stubs und das Erstellen eines dreizeiligen Programms zum Aufrufen der Funktion.

5. " Warum benötigen wir für jede Ressource eine" lesbare "URL? Wenn wir ein Tool zur Implementierung des Dienstes verwenden, interessiert uns die tatsächliche URL wirklich? "

   Wenn Sie sich ansehen, wie das Web funktioniert, bin ich mir ziemlich sicher, dass die Menschen im Großen und Ganzen froh sind, dass die URI für eine Wikipedia-Seite http://en.wikipedia.org/wiki/Stack_overflowstattdessen so aussieht http://en.wikipedia.org/wiki/?oldid=376349090. Aber es ist eigentlich nicht wichtig, sich auszuruhen. Das Wichtigste, um zu versuchen, das Richtige zu tun, ist die Auswahl relevanter Daten in der URI, die sich wahrscheinlich nicht ändern. Sie denken vielleicht, dass sich die Datenbank-ID niemals ändern wird, aber was passiert, wenn zwei Datensätze zusammengeführt werden müssen? Alle Ihre Primärschlüssel ändern sich. Der Seitentitel (Stack_overflow) ändert sich nicht.

Entschuldigen Sie die lange Antwort, aber ich glaube, diese Frage ist gültig und wurde hier auf SO noch nicht beantwortet. Ich bin sicher, Darrel Miller wird seine Antwort hinzufügen, sobald er auch zurück ist.

Bearbeiten: Formatierung

Martin Fowler hat einen Beitrag zum Richardson Maturity Model verfasst, der den Unterschied zwischen SOAP und REST hervorragend erklärt.

WSDL- und andere Protokolle auf Dokumentebene sind redundant. Das HTTP-Protokoll unterstützt neben der Bereitstellung von Dokumenten und dem Senden von Formularen eine viel umfangreichere Reihe von Vorgängen.

Unterstützer von REST fühlen sich mit dieser Redundanz unwohl.