Was ist REST? Leicht verwirrt [geschlossen]

Ich war unter der Annahme, dass REST ein Webdienst ist, aber es scheint, dass ich falsch darin denke - also, was ist REST?

Ich habe Wikipedia durchgelesen, kann mich aber immer noch nicht ganz darum kümmern. Warum werden APIs an vielen Stellen als REST-APIs bezeichnet?

REST ist kein spezifischer Webdienst, sondern ein Entwurfskonzept (Architektur) zur Verwaltung von Statusinformationen. Das wegweisende Papier dazu war Roy Thomas Fieldings Dissertation (2000) "Architekturstile und das Design netzwerkbasierter Softwarearchitekturen" ( online erhältlich an der University of California, Irvine).

Lesen Sie zuerst den Beitrag von Ryan Tomayko. Wie ich meiner Frau REST erklärte ; Es ist ein guter Ausgangspunkt. Lesen Sie dann die aktuelle Dissertation von Fielding. Es ist weder so fortgeschritten noch lang (sechs Kapitel, 180 Seiten)! (Ich weiß, dass Sie Kinder in der Schule es kurz mögen).

EDIT: Ich finde es sinnlos zu versuchen, REST zu erklären. Es gibt so viele Konzepte wie Skalierbarkeit, Sichtbarkeit (zustandslos) usw., die der Leser verstehen muss, und die beste Quelle für das Verständnis sind die eigentlichen Dissertationen. Es ist viel mehr als POST / GET usw.

REST ist ein Software-Entwurfsmuster, das normalerweise für Webanwendungen verwendet wird. Für Laien bedeutet dies, dass es sich um eine häufig verwendete Idee handelt, die in vielen verschiedenen Projekten verwendet wird. Es steht für REpresentational State Transfer . Die Grundidee von REST besteht darin, Objekte auf der Serverseite (wie in Zeilen in einer Datenbanktabelle) als Ressourcen zu behandeln, die erstellt oder zerstört werden können.

Die grundlegendste Art, über REST nachzudenken, besteht darin, die URLs Ihrer Webanwendungen zu formatieren. Wenn Ihre Ressource beispielsweise "Beiträge" heißt, dann:

/posts Wäre, wie ein Benutzer auf ALLE Beiträge zugreifen würde, um sie anzuzeigen.

/posts/:id Auf diese Weise würde ein Benutzer auf einen einzelnen Beitrag zugreifen und diesen anzeigen, der anhand seiner eindeutigen ID abgerufen wird.

/posts/new So würden Sie ein Formular zum Erstellen eines neuen Beitrags anzeigen.

Senden einer POST - Anforderung /userswäre, wie Sie tatsächlich würde erstellen auf der Datenbank - Ebene einen neuen Beitrag.

Wenn Sie eine PUT-Anfrage an senden, /users/:idaktualisieren Sie die Attribute eines bestimmten Beitrags, der wiederum durch eine eindeutige ID gekennzeichnet ist.

Wenn Sie eine DELETE-Anfrage an senden, /users/:idlöschen Sie einen bestimmten Beitrag, der wiederum durch eine eindeutige ID gekennzeichnet ist.

Soweit ich weiß, wurde das REST-Muster hauptsächlich (für Web-Apps) vom Ruby on Rails-Framework populär gemacht, das einen großen Schwerpunkt auf RESTful-Routen legt. Da könnte ich mich allerdings irren.

Ich bin vielleicht nicht der qualifizierteste, um darüber zu sprechen, aber so habe ich es gelernt (speziell für die Rails-Entwicklung).

Wenn sich jemand auf eine "REST-API" bezieht, bedeutet dies im Allgemeinen eine API, die RESTful-URLs zum Abrufen von Daten verwendet.

RESTist ein Architekturstil und ein Design für netzwerkbasierte Softwarearchitekturen.

RESTKonzepte werden als Ressourcen bezeichnet. Eine Darstellung einer Ressource muss zustandslos sein. Es wird über einen Medientyp dargestellt. Einige Beispiele für Medientypen umfassen XML, JSONund RDF. Ressourcen werden von Komponenten manipuliert. Komponenten fordern Ressourcen an und bearbeiten sie über eine einheitliche Standardschnittstelle. Im Fall von HTTP, diese Schnittstelle besteht aus Standard - HTTP - ops zB GET, PUT, POST, DELETE.

RESTwird in der Regel verwendet HTTP, hauptsächlich aufgrund der Einfachheit von HTTP und seiner sehr natürlichen Zuordnung zu RESTful-Prinzipien. REST ist jedoch nicht an ein bestimmtes Protokoll gebunden.

Grundlegende REST-Prinzipien

Client-Server-Kommunikation

Client-Server-Architekturen weisen eine sehr unterschiedliche Trennung von Bedenken auf. Alle im RESTful-Stil erstellten Anwendungen müssen grundsätzlich auch Client-Server sein.

Staatenlos

Für jede Clientanforderung an den Server muss der Status vollständig dargestellt werden. Der Server muss in der Lage sein, die Clientanforderung vollständig zu verstehen, ohne einen Serverkontext oder einen Serversitzungsstatus zu verwenden. Daraus folgt, dass der gesamte Status auf dem Client beibehalten werden muss. Wir werden später auf die staatenlose Darstellung näher eingehen.

Cacheable

Cache-Einschränkungen können verwendet werden, sodass Antwortdaten als zwischenspeicherbar oder nicht zwischenspeicherbar markiert werden können. Alle als zwischenspeicherbar gekennzeichneten Daten können als Antwort auf dieselbe nachfolgende Anforderung wiederverwendet werden.

Einheitliche Schnittstelle

Alle Komponenten müssen über eine einzige einheitliche Schnittstelle interagieren. Da die gesamte Komponenteninteraktion über diese Schnittstelle erfolgt, ist die Interaktion mit verschiedenen Diensten sehr einfach. Die Schnittstelle ist die gleiche! Dies bedeutet auch, dass Implementierungsänderungen isoliert vorgenommen werden können. Solche Änderungen wirken sich nicht auf die grundlegende Komponenteninteraktion aus, da die einheitliche Schnittstelle immer unverändert bleibt. Ein Nachteil ist, dass Sie mit der Schnittstelle stecken bleiben. Wenn durch Ändern der Schnittstelle eine Optimierung für einen bestimmten Dienst bereitgestellt werden könnte, haben Sie kein Glück, da REST dies verbietet. Positiv zu vermerken ist jedoch, dass REST für das Web optimiert ist, weshalb REST über HTTP unglaublich beliebt ist!

Die obigen Konzepte stellen definierende Merkmale von REST dar und unterscheiden die REST-Architektur von anderen Architekturen wie Webdiensten. Es ist nützlich zu beachten, dass ein REST-Service ein Web-Service ist, ein Web-Service jedoch nicht unbedingt ein REST-Service.

Sehen Sie dieses Blog Post auf REST Design - Principals für weitere Details über REST und die oben genannten Grundsätze.

Es steht für Representational State Transfer und kann viele Dinge bedeuten. Wenn Sie jedoch über APIs und Anwendungen sprechen, sprechen Sie normalerweise über REST, um Webdienste zu erstellen oder Programme dazu zu bringen, über das Web zu sprechen.

REST ist im Grunde eine Art der Kommunikation zwischen Systemen und macht einen Großteil dessen, wofür SOAP RPC entwickelt wurde. Während SOAP im Allgemeinen eine Verbindung herstellt, authentifiziert und dann Dinge über diese Verbindung erledigt, funktioniert REST fast genauso wie das Web . Sie haben eine URL und wenn Sie diese URL anfordern, erhalten Sie etwas zurück. Hier werden die Dinge verwirrend, weil die Leute das Web als die größte REST-Anwendung beschreiben und obwohl dies technisch korrekt ist, hilft es nicht wirklich zu erklären, was es ist.

Kurz gesagt, mit REST können Sie zwei Anwendungen mit Tools über das Internet kommunizieren lassen, die denen eines Webbrowsers ähneln. Dies ist viel einfacher als SOAP und vieles, was REST tut, ist zu sagen: "Hey, die Dinge müssen nicht so komplex sein."

Lesenswert:

• Wie ich meiner Frau REST erklärte (jetzt hier erhältlich)
• Architekturstile und das Design netzwerkbasierter Softwarearchitekturen

http://en.wikipedia.org/wiki/Representational_State_Transfer

Die Grundidee ist, dass Sie anstelle einer laufenden Verbindung zum Server eine Anfrage stellen, einige Daten abrufen, diese einem Benutzer zeigen, aber möglicherweise nicht alle, und dann, wenn der Benutzer etwas tut, das mehr Daten erfordert, oder um einige an den Server weiterzuleiten, initiiert der Client eine Änderung in einen neuen Status.