Lassen Sie mich Ihnen kurz ausruhen. Ich habe dich da erwischt.
Was ich sagen wollte, war, lassen Sie mich Ihnen
einen kurzen Überblick über die Übertragung des Vertretungsstaats geben.
Was genau ist REST?
Wie nutzen wir es in unserer React-Anwendung
und wie nutzen wir dies für die Kommunikation mit dem Server?
Wie unterstützt ein Server die REST-API
und wie greifen wir über unsere React-Anwendung auf die REST-API zu?
Lassen Sie uns darüber in dieser Lektion ein wenig mehr sprechen.
Ich bin sicher, dass Sie den Begriff Web-Services in der IT-Welt sehr oft gehört haben.
Was genau sind Webdienste?
Web Services sind eine Möglichkeit, Systeme zu entwerfen, um die Interoperabilität
zwischen Systemen zu unterstützen, die über ein Netzwerk wie das Internet verbunden sind, wie wir heute sehen.
Dies ist, was wir als serviceorientierte Architektur bezeichnen.
Das bedeutet nun, dass
zwei Computer, die
mit dem Internet verbunden sind, eine standardisierte Möglichkeit bieten, auf
Anwendungsebene für webbasierte Anwendungen unter Verwendung offener Standards miteinander zu kommunizieren.
Ich habe dort eine Menge Jargon verwendet.
Lassen Sie uns versuchen, sie zusammenzureißen und
ein wenig darüber in diesem Vortrag zu verstehen.
Zwei gängige Ansätze, die zur Unterstützung von Webdiensten verwendet werden, sind SOAP.
Die auf Simple Object Access Protocol basierenden
Webdienste, die die Beschreibungssprache für Webdienste verwenden,
um anzugeben, wie die beiden Endpunkte miteinander kommunizieren.
Normalerweise basiert SOAP auf der Verwendung von XML als
Format für die Nachrichten, die zwischen den beiden Endpunkten ausgetauscht werden.
Representational State Transfer oder REST verwendet auch Webstandards,
aber der Datenaustausch zwischen den beiden Endpunkten könnte entweder XML sein oder
zunehmend JSON als Format verwenden.
Der REST-Weg der Interoperabilität ist einfacher im Vergleich zu SOAP, und daher
hat REST eine viel breitere Bereitstellung in der Webdienste-Welt gefunden.
In der Regel wird die Client-Server-Kommunikation
mithilfe von REST erleichtert, wobei der Server eine REST-API unterstützt und
der Client dann die REST-API-Endpunkte aufrufen kann,
um Informationen zu erhalten oder Informationen auf den Server hochzuladen.
Auch hier habe ich das Wort Aufruf der REST-API-Endpunkte erwähnt,
also sind dies ein paar Begriffe, die ich verwendet habe.
Lassen Sie uns einige davon in den nächsten Folien klären.
Representational State Transfer ist ein Stil der Software-Architektur
, die speziell für verteilte Hypermedia über das World Wide Web entwickelt wurde.
Nun wurde dies zuerst von Roy Fielding in seiner Dissertation vorgestellt.
Dies ist eine dieser Doktorarbeiten,
die tatsächlich etwas Nützliches für die Welt produziert haben.
Das hat also wieder viel Traktion in der Web-Services-Welt gefunden.
Dies ist eine Sammlung von Netzwerkprinzipien, in denen beschrieben wird, wie
Ressourcen auf Servern zur Verfügung gestellt werden
können und auf diese Ressourcen von Clients zugegriffen werden kann,
indem die Ressourcen mithilfe von restlichen API-Endpunkten identifiziert werden.
Innerhalb der Representational State Transfer
gibt es vier grundlegende Gestaltungsprinzipien.
In erster Linie basiert REST auf dem HTTP-Protokoll,
so dass es alle HTTP-Methoden verwendet, die wir bereits in der vorherigen Lektion gesehen haben.
Zweitens ist REST so konzipiert,
dass er zustandslos ist, was bedeutet, dass der Server
nach Abschluss der Kommunikation keine Informationen über den Status speichert.
Wenn also ein Server die Anforderung empfängt, antwortet der Server,
und danach erinnert er sich an
nichts mehr über die Konversation zwischen dem Client und dem Server.
Drittens besteht die REST-Methode zur Bereitstellung von Ressourcen darin,
eine Verzeichnisstruktur wie URLs (Uniform Resource Locators - URLs) bereitzustellen.
Viertens ist das Format für den Datenaustausch in der Regel JSON
oder XML, oder beide können mit REST unterstützt werden.
Eine der Motivationen für Roy, die REST als eine Möglichkeit zur Unterstützung von Webdiensten vorschlägt
, ist, dass es alle Dinge erfasst,
die im World Wide Web gut sind und das World Wide Web erfolgreich gemacht hat.
Die Verwendung von Uniform Resource Indicators oder
Uniform Resource Locators (URLs), mit denen Sie
Ressourcen adressieren können, indem Sie sie als URL angeben.
Die zweite ist ein Protokoll, das auf dem HTTP-Protokoll lebt.
HTTP hat bereits eine breite Bereitstellung im Internet gefunden.
Drittens, der Anforderungsantwort Zyklus, für den HTTP bekannt ist.
So senden Sie eine Anfrage,
der Server empfängt Ihre Anfrage, verarbeitet die Anfrage,
sendet die Antwort an die Anfrage,
und der Client empfängt die Antwort,
reagiert darauf und generiert möglicherweise weitere Anfragen.
Daher ist dieser Ansatz des Anforderungsantwortzyklus
mit HTTP und dem World Wide Web sehr gut etabliert.
Nun, das HTTP-Protokoll, wie wir früher gesehen haben,
werden wir alle verschiedenen Verben verwenden, die HTTP bietet.
speziell die GET, PUT,
POST und DELETE, um
Operationen angeben zu können, die auf Ressourcen ausgeführt werden, die auf der Serverseite gespeichert sind.
Wenn Sie beispielsweise eine HTTP GET-Anforderung ausführen,
fragen Sie nach dem Server, um die Ressource zurückzugeben.
Wenn Sie eine POST-Anforderung ausführen,
fragen Sie nach dem Server, um eine neue Ressource zu erstellen.
Wenn Sie eine PUT-Anforderung ausführen,
bitten Sie den Server, eine vorhandene Ressource zu aktualisieren.
Und wenn Sie eine DELETE-Anforderung ausgeben,
bitten Sie den Server, die Ressource zu löschen
, die durch die bestimmte URL identifiziert wird.
Außerdem versucht es, Idempotenz zu bewahren.
Einige Operationen, wenn sie sogar wiederholt ausgeführt
werden, verursachen keine Zustandsänderung.
Einige andere Operationen, wenn Sie sie nacheinander tun,
können sie eine Änderung des Zustands verursachen.
Daher müssen Sie vorsichtig sein, welche Operationen
ohne schädliche Folgen wiederholt werden können und welche sehr sorgfältig durchgeführt werden müssen.
In der REST-Welt hören Sie oft Leute, die über Substantive, Verben und Darstellungen sprechen.
In den nächsten Folien werden wir jedes einzelne dieser Folien etwas genauer erläutern.
Substantive beziehen sich speziell auf Ressourcen, und diese Ressourcen werden
normalerweise durch ihre URLs identifiziert, und diese sind nicht eingeschränkt.
Verben sind Einschränkung und diese geben die Aktionen
auf die Ressourcen und Darstellungen durchgeführt werden, wie wir sehen.
Wenn die Informationen vom Server zum
Client oder vom Client zum Server übermittelt werden müssen,
wie Sie die Informationen codieren.
In der Regel entweder mit JSON oder mit XML.
Ressource ist die Schlüsselabstraktion, die REST umgeht.
Die Informationen werden also in Form einer Ressource abstrahiert und die Ressource
wird durch Angabe einer URL identifiziert.
So können alle Informationen, die gekapselt und zur Verfügung gestellt
werden können, als Ressource identifiziert werden.
Eine Information wie das aktuelle Wetter in Hong Kong könnte eine Ressource sein,
ein Bild könnte eine Ressource sein,
eine Aktienkurs-Information könnte eine Ressource sein und so weiter.
Was auch immer Sie als eine Information definieren, an der ein Kunde interessiert sein könnte,
kann als Ressource identifiziert werden.
Sie können sogar Ressourcen als Sammlung von
Ressourcen behandeln, die der Server an den Client senden kann.
Ein Beispiel dafür, wie Sie Ressourcen benennen, wird hier veranschaulicht.
Daher verwenden wir URIs, um die Quelle zu identifizieren.
Ein schnelles Lesen dieser Spezifikation oder der URIs hier
ermöglicht es Ihnen leicht zu verstehen, worauf wir mit diesen URIs verweisen.
So, zum Beispiel, etwas, das mit Gerichten/ endet, gehen
Sie automatisch davon aus, dass sich dies auf eine Sammlung von Gerichten bezieht.
Aber Gerichte/123 zum Beispiel
könnte Gericht Nummer 123 in diesem Fall bedeuten und so weiter.
So ist es sehr einfach zu speichern und Sie können
eine Sammlung von Ressourcen angeben und in der Lage sein,
sie als Sammlung zu identifizieren und dann als Sammlung herunterladen, oder Sie können
eine einzelne Ressource identifizieren und sagen, dass Sie diese bestimmte Ressource wollen.
Nun können diese Ressourcen in einer Hierarchie der Spezifikation dieses URI organisiert werden.
Wenn Sie also den Pfad durchlaufen,
gehen Sie vom allgemeineren zur spezifischeren Ressource.
Diese Verzeichnisstruktur ermöglicht es Ihnen, die Ressourcen
, die Sie auf Ihrer Serverseite verwenden oder bereitstellen, sehr einfach zu identifizieren.
Der zweite Teil der REST-API sind die Verben.
Insbesondere interessieren wir uns für die vier Verben von HTTP die GET,
PUT, POST und DELETE.
In diesem Fall werden diese Verben in Aktionen zugeordnet, die wir
auf der Ressource, auf der Serverseite ausgeführt werden wollen.
Ein GET würde bedeuten, dass Sie einen Lesevorgang für die Ressource ausführen möchten.
Das bedeutet, dass ein Client, der eine GET-Anfrage sendet, an den Server anzeigt,
dass er eine Darstellung dieser Ressource von der Serverseite zur Client-Seite erhalten möchte.
Ein POST bedeutet, dass Sie
eine neue Ressource erstellen möchten und dann die Details der Ressource
in der Darstellung angeben, die für die
Angabe der Ressource verwendet wird, und diese Informationen dann an die serverseitige Seite senden,
damit der Server diese Ressource in Ihrem Namen erstellt.
Ein PUT wäre eine Änderung von Ressourcen und
eine DELETE, wie Sie erwarten würden, ist das Löschen der Ressourcen.
Wie Sie sehen können,
werden die vier Verben GET, POST, PUT und DELETE den vier CRUD-Operationen zugeordnet, die Sie in
einer Datenbank ausführen können, die diese Ressourcen auf der Serverseite speichert, die
READ, CREATE, UPDATE und DELETE.
Ausführend ist das HTTP GET eine Möglichkeit, anzugeben, dass
die Informationen oder die Darstellung
der Ressource vom Server an den Client zurückgegeben werden sollen.
Wenn Sie also eine GET-Anforderung an einen REST-API-Endpunkt ausgeben,
fragen Sie entweder nach einer Sammlung von Ressourcen, die durch
URI dargestellt werden, oder einer bestimmten Ressource, die durch die ID dieser bestimmten Ressource identifiziert wird,
die in der URL angegeben ist.
Also, wie Sie in diesem Beispiel sehen,
wenn Sie sagen, Gerichte/452,
wollen Sie sagen, dass Gericht Nummer 452 mit
der ID 452 an die Client-Seite zurückgegeben werden sollte.
In ähnlicher Weise wird die POST-Operation, wie wir sahen, verwendet, um die Ressource zu erstellen.
Wenn Sie also die Ressource erstellen,
wird der Inhalt der Beschreibung der Ressource in Form einer JSON-Repräsentation oder
einer XML-Repräsentation vorliegen, die im
Hauptteil der Anforderungsnachricht enthalten wird, die an die serverseitige Seite gesendet wird.
Daher erwartet ein POST-Vorgang eine Darstellung
der Ressource im JSON- oder XML-Format im Hauptteil der Anforderungsnachricht.
Wenn der Server diese Anforderungsnachricht empfängt,
erstellt der Server diese Ressource auf der Serverseite und gibt dann
entweder eine Konformation oder einen Fehler zurück, der darauf hinweist, dass die Ressourcenerstellung fehlgeschlagen ist.
In ähnlicher Weise wird eine PUT-Operation verwendet, um eine Ressource zu aktualisieren.
Wenn Sie eine PUT-Operation für eine Ressource auf der Serverseite ausführen,
können Sie die Änderung
entweder zurücksenden, indem Sie nur die Teiländerung angeben, die Sie auf
die bestimmte Ressource im Textkörper der Antwortnachricht auswirken möchten, oder Sie können
die vollständige Darstellung der -Ressource im Nachrichtentext.
Abhängig von der Anordnung zwischen dem Client und dem Server
erwartet der Server, dass die Informationen im Textkörper der Anforderungsnachricht weitergegeben werden.
Ein DELETE-Vorgang, wie Sie erwarten, löscht die vorhandene Ressource.
Nun, in diesem speziellen Fall,
wäre natürlich eine DELETE-Operation idempotent, denn wenn Sie
versuchen, eine Ressource zu löschen und die Ressource existiert, wird sie gelöscht.
Wenn Sie versuchen, eine nicht vorhandene Ressource zu löschen,
führt dies zu keiner weiteren Änderung auf der Serverseite,
außer dass der Server mit einer Fehlermeldung antwortet, die besagt, dass die Ressource nicht existiert.
Dennoch ist DELETE in diesem Fall ein Beispiel für eine idempotente Operation.
In ähnlicher Weise ist die GET-Operation auch eine idempotente Operation, da sie
keine Änderungen an der Ressource auf der Serverseite vornimmt.
POST und PUT werden natürlich die Ressource auf der Serverseite ändern,
entweder eine neue Ressource erstellen oder eine vorhandene Ressource auf der Serverseite ändern.
Natürlich sind die Repräsentationen,
wie ich betont habe,
die beiden gängigen Formate für die Darstellung entweder JSON oder XML.
Der letzte Teil, den wir betonen müssen
, ist, dass serverseitig völlig zustandslos sein sollte,
was bedeutet, dass die serverseitige Seite
den Clientstatus nicht verfolgt, denn wenn der Server den Clientstatus verfolgen muss,
ist er nicht skalierbar.
Für eine skalierbare Implementierung der serverseitigen,
verwenden Sie normalerweise einen zustandslosen Server auf der Serverseite.
Daher wird jede Anforderung, die der Client an den Server sendet,
als unabhängige Anforderung behandelt und
spiegelt nicht auf vorherige Anforderungen wider
, die bereits vom Server von diesem bestimmten Client verarbeitet wurden.
Es liegt also in der Verantwortung des Kunden, seinen eigenen Zustand zu verfolgen,
entweder in Form von Cookies oder mit einer clientseitigen Datenbank,
was auch immer geeignet ist.
Nun ist dieser Ansatz, bei dem der Client seinen eigenen Status verfolgt,
viel skalierbarer, da jeder einzelne Client
für die Verfolgung seines eigenen Status verantwortlich ist.
Hier hilft uns das clientseitige MVC-Setup in dieser Hinsicht.
Schließlich sind wir noch nicht mit REST fertig.
Wir werden mehr von REST in den Übungen sehen, die in dieser speziellen Lektion folgen,
und dann werden wir auch weitere Details zur REST-Verwendung im Rest dieses Kurses sehen.