Anscheinend ist REST nur eine Reihe von Konventionen zur Verwendung von HTTP . Ich frage mich, welchen Vorteil diese Konventionen bieten. Weiß jemand?

Ich glaube nicht, dass Sie eine gute Antwort darauf bekommen werden, auch weil sich niemand wirklich darüber einig ist, was REST ist . Die Wikipedia-Seite ist voller Schlagworte und leicht zu erklären. Die Diskussionsseite ist einen Blick wert, nur um zu sehen, wie viele Menschen diesbezüglich nicht einverstanden sind. Soweit ich jedoch sagen kann, bedeutet REST Folgendes:

Statt zufällig benannte Setter und Getter URLs zu haben und mit GETallen den Getter und POSTfür alle Setter, versuchen wir , die URLs Ressourcen identifizieren zu haben, und dann die HTTP - Aktionen verwenden GET, POST, PUTund DELETESachen zu ihnen zu tun. Also statt

GET /get_article?id=1
POST /delete_article   id=1

Du würdest

GET /articles/1/
DELETE /articles/1/

Und dann POSTund PUTentsprechen "Erstellen" und "Aktualisieren" (aber niemand stimmt zu, in welche Richtung).

Ich denke, die Caching-Argumente sind falsch, weil Abfragezeichenfolgen im Allgemeinen zwischengespeichert werden und Sie sie außerdem nicht wirklich verwenden müssen. Zum Beispiel macht Django so etwas sehr einfach, und ich würde nicht sagen, dass es REST war:

GET /get_article/1/
POST /delete_article/     id=1

Oder fügen Sie einfach das Verb in die URL ein:

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

In diesem Fall GETbedeutet dies etwas ohne Nebenwirkungen und POSTbedeutet etwas, das die Daten auf dem Server ändert. Ich denke , das ist vielleicht ein wenig klarer und einfacher, vor allem , wie Sie die ganze vermeiden PUT-vs- POSTSache. Außerdem können Sie weitere Verben hinzufügen, wenn Sie möchten, sodass Sie nicht künstlich an das gebunden sind, was HTTP bietet. Beispielsweise:

POST /hide/article/1/
POST /show/article/1/

(Oder was auch immer, es ist schwer, sich Beispiele vorzustellen, bis sie eintreten!)

Zusammenfassend kann ich also nur zwei Vorteile erkennen:

1. Ihre Web-API ist möglicherweise sauberer und leichter zu verstehen / zu entdecken.
2. Wenn Sie Daten mit einer Website synchronisieren, ist es wahrscheinlich einfacher, REST zu verwenden, da Sie einfach sagen können synchronize("/articles/1/")oder was auch immer. Dies hängt stark von Ihrem Code ab.

Ich denke jedoch, dass es einige ziemlich große Nachteile gibt:

1. Nicht alle Aktionen lassen sich leicht auf CRUD abbilden (erstellen, lesen / abrufen, aktualisieren, löschen). Möglicherweise haben Sie nicht einmal mit Objekttypressourcen zu tun.
2. Es ist ein zusätzlicher Aufwand für zweifelhafte Vorteile.
3. Verwirrung darüber, in welche Richtung PUTund POSTsind. Auf Englisch bedeuten sie ähnliche Dinge ("Ich werde einen Hinweis an die Wand hängen / posten.").

Abschließend würde ich sagen: Speichern Sie REST für die zweite Version Ihrer API, es sei denn, Sie möchten wirklich zusätzliche Anstrengungen unternehmen oder wenn Ihr Service wirklich gut auf CRUD-Operationen abgebildet wird.

Ich bin gerade auf ein anderes Problem mit REST gestoßen: Es ist nicht einfach, mehr als eine Sache in einer Anfrage zu erledigen oder anzugeben, welche Teile eines zusammengesetzten Objekts Sie erhalten möchten. Dies ist besonders wichtig auf Mobilgeräten, bei denen die Umlaufzeit erheblich sein kann und die Verbindungen unzuverlässig sind. Angenommen, Sie erhalten Beiträge auf einer Facebook-Timeline. Der "reine" REST-Weg wäre so etwas wie

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

Welches ist irgendwie lächerlich. Die Facebook-API ist IMO ziemlich gut, also lasst uns sehen, was sie tun:

Standardmäßig werden die meisten Objekteigenschaften zurückgegeben, wenn Sie eine Abfrage durchführen. Sie können die Felder (oder Verbindungen) auswählen, die mit dem Abfrageparameter "Felder" zurückgegeben werden sollen. Diese URL gibt beispielsweise nur die ID, den Namen und das Bild von Ben zurück: https://graph.facebook.com/bgolub?fields=id,name,picture

Ich habe keine Ahnung, wie Sie so etwas mit REST machen würden, und wenn Sie das tun würden, würde es immer noch als REST gelten. Ich würde jeden ignorieren, der versucht, Ihnen zu sagen, dass Sie das nicht tun sollten (besonders wenn der Grund "weil es nicht REST ist" ist)!

Einfach ausgedrückt bedeutet REST, HTTP so zu verwenden, wie es sein soll.

Schauen Sie sich Roy Fieldings Dissertation über REST an . Ich denke, dass jede Person, die Webentwicklung macht, es lesen sollte.

Roy Fielding ist auch einer der wichtigsten Treiber für das HTTP-Protokoll.

Um einige der Vorteile zu nennen:

• Einfach.
• Sie können den HTTP-Cache und den Proxyserver gut nutzen, um mit hoher Last umzugehen.
• Es hilft Ihnen, selbst eine sehr komplexe Anwendung in einfachen Ressourcen zu organisieren.
• Dies erleichtert neuen Kunden die Verwendung Ihrer Anwendung, auch wenn Sie sie nicht speziell für sie entwickelt haben (wahrscheinlich, weil sie bei der Erstellung Ihrer App nicht vorhanden waren).

Einfach ausgedrückt: KEINE .

Fühlen Sie sich frei, abzustimmen, aber ich denke immer noch, dass es keine wirklichen Vorteile gegenüber Nicht-REST-HTTP gibt. Alle aktuellen Antworten sind ungültig. Argumente aus der derzeit am häufigsten gewählten Antwort:

• Einfach.
• Sie können den HTTP-Cache und den Proxyserver gut nutzen, um mit hoher Last umzugehen.
• Es hilft Ihnen, selbst eine sehr komplexe Anwendung in einfachen Ressourcen zu organisieren.
• Dies erleichtert neuen Kunden die Verwendung Ihrer Anwendung, auch wenn Sie sie nicht speziell für sie entwickelt haben (wahrscheinlich, weil sie bei der Erstellung Ihrer App nicht vorhanden waren).

1. Einfach

Mit REST benötigen Sie eine zusätzliche Kommunikationsschicht für Ihre serverseitigen und clientseitigen Skripte => Dies ist tatsächlich komplizierter als die Verwendung von Nicht-REST-HTTP.

2. Caching

Das Caching kann über vom Server gesendete HTTP-Header gesteuert werden. REST fügt keine Funktionen hinzu, die in Nicht-REST fehlen.

3. Organisation

REST hilft Ihnen nicht bei der Organisation. Sie werden gezwungen , eine API zu verwenden, die von der von Ihnen verwendeten serverseitigen Bibliothek unterstützt wird. Sie können Ihre Anwendung auf die gleiche Weise (oder besser) organisieren, wenn Sie einen Nicht-REST-Ansatz verwenden. Siehe z. B. Model-View-Controller oder MVC-Routing .

4. Einfach zu bedienen / zu implementieren

Überhaupt nicht wahr. Es hängt alles davon ab, wie gut Sie Ihre Bewerbung organisieren und dokumentieren. REST wird Ihre Anwendung nicht auf magische Weise verbessern.

IMHO ist der größte Vorteil, den REST ermöglicht, die Reduzierung der Client / Server-Kopplung. Es ist viel einfacher, eine REST-Schnittstelle im Laufe der Zeit weiterzuentwickeln, ohne vorhandene Clients zu beschädigen.

Auffindbarkeit

Jede Ressource enthält Verweise auf andere Ressourcen, entweder in Hierarchie oder in Links, sodass das Durchsuchen einfach ist. Dies ist ein Vorteil für den Menschen, der den Kunden entwickelt, indem er nicht ständig die Dokumente konsultiert und Vorschläge macht. Dies bedeutet auch, dass der Server Ressourcennamen einseitig ändern kann (solange die Client-Software die URLs nicht fest codiert).

Kompatibilität mit anderen Tools

Sie können sich in einen beliebigen Teil der API einarbeiten oder mit dem Webbrowser durch Ressourcen navigieren. Erleichtert das Debuggen und Testen der Integration erheblich.

Standardisierte Verbnamen

Ermöglicht das Festlegen von Aktionen, ohne den richtigen Wortlaut suchen zu müssen. Stellen Sie sich vor, OOP-Getter und -Setter wären nicht standardisiert, und einige Leute verwenden retrieveund definestattdessen. Sie müssten sich für jeden einzelnen Zugangspunkt das richtige Verb merken. Zu wissen, dass nur eine Handvoll Verben verfügbar sind, wirkt diesem Problem entgegen.

Standardisierter Status

Wenn Sie GETeine Ressource haben, die nicht vorhanden ist, können Sie sicher sein, dass 404in einer RESTful-API ein Fehler angezeigt wird. Vergleichen Sie es mit einer nicht-RESTful-API, die möglicherweise {error: "Not found"}in Gott weiß wie viele Ebenen verpackt zurückkehrt. Wenn Sie zusätzlichen Speicherplatz benötigen, um eine Nachricht an den Entwickler auf der anderen Seite zu schreiben, können Sie immer den Hauptteil der Antwort verwenden.

Beispiel

Stellen Sie sich zwei APIs mit derselben Funktionalität vor, eine nach REST und die andere nicht. Stellen Sie sich nun die folgenden Clients für diese APIs vor:

RUHIG:

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

HTTP:

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

Denken Sie nun an folgende Fragen:

• Wenn der erste Anruf jedes Kunden funktioniert hat, wie sicher können Sie sein, dass der Rest auch funktioniert?

• Es gab ein umfangreiches Update der API, durch das diese Zugriffspunkte möglicherweise geändert wurden oder nicht. Wie viele Dokumente müssen Sie erneut lesen?

• Können Sie die Rückkehr der letzten Abfrage vorhersagen?

• Sie müssen die veröffentlichte Bewertung bearbeiten (bevor Sie sie löschen). Können Sie dies tun, ohne die Dokumente zu überprüfen?

Ich empfehle einen Blick auf Ryan Tomaykos Wie ich meiner Frau REST erklärte

Bearbeitung durch Dritte

Auszug aus dem Waybackmaschine-Link:

Wie wäre es mit einem Beispiel. Sie sind Lehrer und möchten Schüler verwalten:

• in welchen Klassen sie sind,
• welche Noten sie bekommen,
• Notfallkontakte,
• Informationen zu den Büchern, aus denen Sie unterrichten usw.

Wenn die Systeme webbasiert sind, gibt es wahrscheinlich eine URL für jedes der hier beteiligten Substantive : student, teacher, class, book, room, etc. ... Wenn es für jede URL eine maschinenlesbare Darstellung gäbe, wäre es trivial, neue Tools auf dem System zu speichern, da all diese Informationen auf standardmäßige Weise konsumiert werden könnten. ... Sie könnten ein landesweites System aufbauen, das mit jedem einzelnen Schulsystem sprechen kann, um Testergebnisse zu sammeln.

Jedes der Systeme würde mithilfe eines einfachen HTTP-GET Informationen voneinander erhalten. Wenn ein System einem anderen System etwas hinzufügen muss, wird ein HTTP-POST verwendet. Wenn ein System etwas in einem anderen System aktualisieren möchte, verwendet es einen HTTP-PUT. Sie müssen nur noch herausfinden, wie die Daten aussehen sollen.

Ich würde jedem empfehlen, der nach einer Antwort auf diese Frage sucht, diese "Diashow" durchzugehen .

Ich konnte nicht verstehen, was REST ist und warum es so cool ist, seine Vor- und Nachteile, Unterschiede zu SOAP - aber diese Diashow war so brillant und leicht zu verstehen, dass es mir jetzt viel klarer ist als zuvor.

Caching.

Es gibt noch weitere tiefgreifende Vorteile von REST, bei denen es um die Entwicklungsfähigkeit durch lose Kopplung und Hypertext geht. Caching-Mechanismen sind jedoch der Hauptgrund, warum Sie sich für RESTful HTTP interessieren sollten.

Es ist in der Fielding-Dissertation niedergeschrieben . Aber wenn Sie nicht viel lesen wollen:

• erhöhte Skalierbarkeit (aufgrund von Einschränkungen bei Statuslosigkeit, Cache und geschichteten Systemen)
• entkoppelter Client und Server (aufgrund zustandsloser und einheitlicher Schnittstellenbeschränkungen)
  • wiederverwendbare Clients (Client kann allgemeine REST-Browser und RDF-Semantik verwenden, um zu entscheiden, welchem ​​Link gefolgt werden soll und wie die Ergebnisse angezeigt werden sollen)
  • Nicht brechende Clients (Clients brechen nur durch anwendungsspezifische Semantikänderungen, da sie die Semantik anstelle einiger API-spezifischer Kenntnisse verwenden.)

• Geben Sie jeder "Ressource" eine ID
• Dinge miteinander verbinden
• Verwenden Sie Standardmethoden
• Ressourcen mit mehreren Darstellungen
• Staatenlos kommunizieren

Ist es möglich, alles nur mit POST und GET zu machen? Ja, ist es der beste Ansatz? Nein, warum? weil wir Standardmethoden haben. Wenn Sie noch einmal darüber nachdenken, wäre es möglich, alles nur mit GET zu erledigen. Warum sollten wir uns also überhaupt die Mühe machen, POST zu verwenden? Wegen der Standards!

Wenn Sie heute beispielsweise an ein MVC-Modell denken, können Sie Ihre Anwendung so einschränken, dass sie nur auf bestimmte Arten von Verben wie POST, GET, PUT und DELETE reagiert. Auch wenn unter der Haube alles zu POST und GET emuliert ist, macht es keinen Sinn, unterschiedliche Verben für unterschiedliche Aktionen zu haben?

Die Erkennung ist in REST viel einfacher. Wir haben WADL-Dokumente (ähnlich wie WSDL in herkömmlichen Webservices), mit denen Sie Ihren Service weltweit bekannt machen können. Sie können auch UDDI-Entdeckungen verwenden. Bei herkömmlichen HTTP-POST- und GET-Programmen kennen die Benutzer möglicherweise Ihre Nachrichtenanforderungs- und Antwortschemata nicht, um Sie anzurufen.

Ein Vorteil ist, dass wir XML-Dokumente nicht sequentiell verarbeiten und XML-Daten aus verschiedenen Quellen wie dem InputStream-Objekt, einer URL, einem DOM-Knoten ...

@Timmmm, über deine Bearbeitung:

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

Dies würde die Anzahl der Anrufe drastisch reduzieren

Und nichts hindert Sie daran, einen Server zu entwerfen, der HTTP-Parameter akzeptiert, um die Feldwerte anzugeben, die Ihre Clients möglicherweise wünschen ...

Aber das ist ein Detail.

Viel wichtiger ist die Tatsache, dass Sie keine großen Vorteile des REST-Architekturstils erwähnt haben (viel bessere Skalierbarkeit aufgrund von Serverzustandslosigkeit, viel bessere Verfügbarkeit aufgrund von Serverzustandslosigkeit, viel bessere Nutzung der Standarddienste wie Caching für Zum Beispiel bei Verwendung eines REST-Architekturstils, viel geringere Kopplung zwischen Client und Server aufgrund der Verwendung einer einheitlichen Schnittstelle usw. usw.)

Wie für Ihre Bemerkung

"Nicht alle Aktionen lassen sich leicht auf CRUD abbilden (erstellen, lesen / abrufen, aktualisieren, löschen)."

: Ein RDBMS verwendet ebenfalls einen CRUD-Ansatz (SELECT / INSERT / DELETE / UPDATE), und es gibt immer eine Möglichkeit, ein Datenmodell darzustellen und darauf zu reagieren.

In Bezug auf Ihren Satz

"Möglicherweise haben Sie nicht einmal mit Objekttypressourcen zu tun."

: Ein RESTful-Design ist im Wesentlichen ein einfaches Design - dies bedeutet jedoch NICHT, dass das Design einfach ist. Sehen Sie den Unterschied? Sie müssen viel über die Konzepte nachdenken, die Ihre Anwendung darstellen und handhaben wird. Was muss sie tun, wenn Sie dies vorziehen, um dies mithilfe von Ressourcen darzustellen? Wenn Sie dies jedoch tun, erhalten Sie ein einfacheres und effizienteres Design.

Abfragezeichenfolgen können von Suchmaschinen ignoriert werden.