1 00:00:03,200 --> 00:00:09,035 Lassen Sie mich Ihnen kurz ausruhen. Ich habe dich da erwischt. 2 00:00:09,035 --> 00:00:11,535 Was ich sagen wollte, war, lassen Sie mich Ihnen 3 00:00:11,535 --> 00:00:16,420 einen kurzen Überblick über die Übertragung des Vertretungsstaats geben. 4 00:00:16,420 --> 00:00:18,460 Was genau ist REST? 5 00:00:18,460 --> 00:00:22,670 Wie nutzen wir es in unserer React-Anwendung 6 00:00:22,670 --> 00:00:26,130 und wie nutzen wir dies für die Kommunikation mit dem Server? 7 00:00:26,130 --> 00:00:29,455 Wie unterstützt ein Server die REST-API 8 00:00:29,455 --> 00:00:34,615 und wie greifen wir über unsere React-Anwendung auf die REST-API zu? 9 00:00:34,615 --> 00:00:39,230 Lassen Sie uns darüber in dieser Lektion ein wenig mehr sprechen. 10 00:00:39,230 --> 00:00:47,680 Ich bin sicher, dass Sie den Begriff Web-Services in der IT-Welt sehr oft gehört haben. 11 00:00:47,680 --> 00:00:49,895 Was genau sind Webdienste? 12 00:00:49,895 --> 00:00:55,520 Web Services sind eine Möglichkeit, Systeme zu entwerfen, um die Interoperabilität 13 00:00:55,520 --> 00:01:01,745 zwischen Systemen zu unterstützen, die über ein Netzwerk wie das Internet verbunden sind, wie wir heute sehen. 14 00:01:01,745 --> 00:01:05,504 Dies ist, was wir als serviceorientierte Architektur bezeichnen. 15 00:01:05,504 --> 00:01:09,170 Das bedeutet nun, dass 16 00:01:09,170 --> 00:01:14,870 zwei Computer, die 17 00:01:14,870 --> 00:01:17,720 mit dem Internet verbunden sind, eine standardisierte Möglichkeit bieten, auf 18 00:01:17,720 --> 00:01:24,660 Anwendungsebene für webbasierte Anwendungen unter Verwendung offener Standards miteinander zu kommunizieren. 19 00:01:24,660 --> 00:01:29,175 Ich habe dort eine Menge Jargon verwendet. 20 00:01:29,175 --> 00:01:32,000 Lassen Sie uns versuchen, sie zusammenzureißen und 21 00:01:32,000 --> 00:01:36,195 ein wenig darüber in diesem Vortrag zu verstehen. 22 00:01:36,195 --> 00:01:43,390 Zwei gängige Ansätze, die zur Unterstützung von Webdiensten verwendet werden, sind SOAP. 23 00:01:43,390 --> 00:01:49,550 Die auf Simple Object Access Protocol basierenden 24 00:01:49,550 --> 00:01:52,805 Webdienste, die die Beschreibungssprache für Webdienste verwenden, 25 00:01:52,805 --> 00:01:57,080 um anzugeben, wie die beiden Endpunkte miteinander kommunizieren. 26 00:01:57,080 --> 00:02:01,700 Normalerweise basiert SOAP auf der Verwendung von XML als 27 00:02:01,700 --> 00:02:07,340 Format für die Nachrichten, die zwischen den beiden Endpunkten ausgetauscht werden. 28 00:02:07,340 --> 00:02:12,975 Representational State Transfer oder REST verwendet auch Webstandards, 29 00:02:12,975 --> 00:02:17,240 aber der Datenaustausch zwischen den beiden Endpunkten könnte entweder XML sein oder 30 00:02:17,240 --> 00:02:22,385 zunehmend JSON als Format verwenden. 31 00:02:22,385 --> 00:02:29,705 Der REST-Weg der Interoperabilität ist einfacher im Vergleich zu SOAP, und daher 32 00:02:29,705 --> 00:02:37,650 hat REST eine viel breitere Bereitstellung in der Webdienste-Welt gefunden. 33 00:02:37,650 --> 00:02:41,215 In der Regel wird die Client-Server-Kommunikation 34 00:02:41,215 --> 00:02:45,830 mithilfe von REST erleichtert, wobei der Server eine REST-API unterstützt und 35 00:02:45,830 --> 00:02:49,960 der Client dann die REST-API-Endpunkte aufrufen kann, 36 00:02:49,960 --> 00:02:54,595 um Informationen zu erhalten oder Informationen auf den Server hochzuladen. 37 00:02:54,595 --> 00:02:59,885 Auch hier habe ich das Wort Aufruf der REST-API-Endpunkte erwähnt, 38 00:02:59,885 --> 00:03:03,210 also sind dies ein paar Begriffe, die ich verwendet habe. 39 00:03:03,210 --> 00:03:07,385 Lassen Sie uns einige davon in den nächsten Folien klären. 40 00:03:07,385 --> 00:03:12,590 Representational State Transfer ist ein Stil der Software-Architektur 41 00:03:12,590 --> 00:03:18,200 , die speziell für verteilte Hypermedia über das World Wide Web entwickelt wurde. 42 00:03:18,200 --> 00:03:24,604 Nun wurde dies zuerst von Roy Fielding in seiner Dissertation vorgestellt. 43 00:03:24,604 --> 00:03:26,990 Dies ist eine dieser Doktorarbeiten, 44 00:03:26,990 --> 00:03:29,660 die tatsächlich etwas Nützliches für die Welt produziert haben. 45 00:03:29,660 --> 00:03:38,690 Das hat also wieder viel Traktion in der Web-Services-Welt gefunden. 46 00:03:38,690 --> 00:03:42,800 Dies ist eine Sammlung von Netzwerkprinzipien, in denen beschrieben wird, wie 47 00:03:42,800 --> 00:03:47,300 Ressourcen auf Servern zur Verfügung gestellt werden 48 00:03:47,300 --> 00:03:50,950 können und auf diese Ressourcen von Clients zugegriffen werden kann, 49 00:03:50,950 --> 00:03:56,285 indem die Ressourcen mithilfe von restlichen API-Endpunkten identifiziert werden. 50 00:03:56,285 --> 00:03:58,855 Innerhalb der Representational State Transfer 51 00:03:58,855 --> 00:04:01,050 gibt es vier grundlegende Gestaltungsprinzipien. 52 00:04:01,050 --> 00:04:05,375 In erster Linie basiert REST auf dem HTTP-Protokoll, 53 00:04:05,375 --> 00:04:11,365 so dass es alle HTTP-Methoden verwendet, die wir bereits in der vorherigen Lektion gesehen haben. 54 00:04:11,365 --> 00:04:15,045 Zweitens ist REST so konzipiert, 55 00:04:15,045 --> 00:04:17,930 dass er zustandslos ist, was bedeutet, dass der Server 56 00:04:17,930 --> 00:04:21,450 nach Abschluss der Kommunikation keine Informationen über den Status speichert. 57 00:04:21,450 --> 00:04:25,615 Wenn also ein Server die Anforderung empfängt, antwortet der Server, 58 00:04:25,615 --> 00:04:29,110 und danach erinnert er sich an 59 00:04:29,110 --> 00:04:33,340 nichts mehr über die Konversation zwischen dem Client und dem Server. 60 00:04:33,340 --> 00:04:38,635 Drittens besteht die REST-Methode zur Bereitstellung von Ressourcen darin, 61 00:04:38,635 --> 00:04:44,945 eine Verzeichnisstruktur wie URLs (Uniform Resource Locators - URLs) bereitzustellen. 62 00:04:44,945 --> 00:04:50,230 Viertens ist das Format für den Datenaustausch in der Regel JSON 63 00:04:50,230 --> 00:04:56,145 oder XML, oder beide können mit REST unterstützt werden. 64 00:04:56,145 --> 00:05:03,350 Eine der Motivationen für Roy, die REST als eine Möglichkeit zur Unterstützung von Webdiensten vorschlägt 65 00:05:03,350 --> 00:05:06,620 , ist, dass es alle Dinge erfasst, 66 00:05:06,620 --> 00:05:10,880 die im World Wide Web gut sind und das World Wide Web erfolgreich gemacht hat. 67 00:05:10,880 --> 00:05:14,040 Die Verwendung von Uniform Resource Indicators oder 68 00:05:14,040 --> 00:05:18,320 Uniform Resource Locators (URLs), mit denen Sie 69 00:05:18,320 --> 00:05:23,170 Ressourcen adressieren können, indem Sie sie als URL angeben. 70 00:05:23,170 --> 00:05:29,390 Die zweite ist ein Protokoll, das auf dem HTTP-Protokoll lebt. 71 00:05:29,390 --> 00:05:34,600 HTTP hat bereits eine breite Bereitstellung im Internet gefunden. 72 00:05:34,600 --> 00:05:40,135 Drittens, der Anforderungsantwort Zyklus, für den HTTP bekannt ist. 73 00:05:40,135 --> 00:05:42,420 So senden Sie eine Anfrage, 74 00:05:42,420 --> 00:05:45,775 der Server empfängt Ihre Anfrage, verarbeitet die Anfrage, 75 00:05:45,775 --> 00:05:49,530 sendet die Antwort an die Anfrage, 76 00:05:49,530 --> 00:05:51,830 und der Client empfängt die Antwort, 77 00:05:51,830 --> 00:05:54,765 reagiert darauf und generiert möglicherweise weitere Anfragen. 78 00:05:54,765 --> 00:05:58,580 Daher ist dieser Ansatz des Anforderungsantwortzyklus 79 00:05:58,580 --> 00:06:03,115 mit HTTP und dem World Wide Web sehr gut etabliert. 80 00:06:03,115 --> 00:06:08,505 Nun, das HTTP-Protokoll, wie wir früher gesehen haben, 81 00:06:08,505 --> 00:06:13,650 werden wir alle verschiedenen Verben verwenden, die HTTP bietet. 82 00:06:13,650 --> 00:06:15,520 speziell die GET, PUT, 83 00:06:15,520 --> 00:06:18,635 POST und DELETE, um 84 00:06:18,635 --> 00:06:23,480 Operationen angeben zu können, die auf Ressourcen ausgeführt werden, die auf der Serverseite gespeichert sind. 85 00:06:23,480 --> 00:06:27,470 Wenn Sie beispielsweise eine HTTP GET-Anforderung ausführen, 86 00:06:27,470 --> 00:06:30,125 fragen Sie nach dem Server, um die Ressource zurückzugeben. 87 00:06:30,125 --> 00:06:32,415 Wenn Sie eine POST-Anforderung ausführen, 88 00:06:32,415 --> 00:06:35,415 fragen Sie nach dem Server, um eine neue Ressource zu erstellen. 89 00:06:35,415 --> 00:06:36,670 Wenn Sie eine PUT-Anforderung ausführen, 90 00:06:36,670 --> 00:06:39,650 bitten Sie den Server, eine vorhandene Ressource zu aktualisieren. 91 00:06:39,650 --> 00:06:42,170 Und wenn Sie eine DELETE-Anforderung ausgeben, 92 00:06:42,170 --> 00:06:45,020 bitten Sie den Server, die Ressource zu löschen 93 00:06:45,020 --> 00:06:48,070 , die durch die bestimmte URL identifiziert wird. 94 00:06:48,070 --> 00:06:51,735 Außerdem versucht es, Idempotenz zu bewahren. 95 00:06:51,735 --> 00:06:56,165 Einige Operationen, wenn sie sogar wiederholt ausgeführt 96 00:06:56,165 --> 00:06:58,225 werden, verursachen keine Zustandsänderung. 97 00:06:58,225 --> 00:07:02,085 Einige andere Operationen, wenn Sie sie nacheinander tun, 98 00:07:02,085 --> 00:07:05,170 können sie eine Änderung des Zustands verursachen. 99 00:07:05,170 --> 00:07:08,780 Daher müssen Sie vorsichtig sein, welche Operationen 100 00:07:08,780 --> 00:07:14,395 ohne schädliche Folgen wiederholt werden können und welche sehr sorgfältig durchgeführt werden müssen. 101 00:07:14,395 --> 00:07:21,864 In der REST-Welt hören Sie oft Leute, die über Substantive, Verben und Darstellungen sprechen. 102 00:07:21,864 --> 00:07:27,875 In den nächsten Folien werden wir jedes einzelne dieser Folien etwas genauer erläutern. 103 00:07:27,875 --> 00:07:31,760 Substantive beziehen sich speziell auf Ressourcen, und diese Ressourcen werden 104 00:07:31,760 --> 00:07:36,320 normalerweise durch ihre URLs identifiziert, und diese sind nicht eingeschränkt. 105 00:07:36,320 --> 00:07:40,700 Verben sind Einschränkung und diese geben die Aktionen 106 00:07:40,700 --> 00:07:45,010 auf die Ressourcen und Darstellungen durchgeführt werden, wie wir sehen. 107 00:07:45,010 --> 00:07:47,285 Wenn die Informationen vom Server zum 108 00:07:47,285 --> 00:07:49,910 Client oder vom Client zum Server übermittelt werden müssen, 109 00:07:49,910 --> 00:07:51,855 wie Sie die Informationen codieren. 110 00:07:51,855 --> 00:07:56,520 In der Regel entweder mit JSON oder mit XML. 111 00:07:56,520 --> 00:08:01,895 Ressource ist die Schlüsselabstraktion, die REST umgeht. 112 00:08:01,895 --> 00:08:06,810 Die Informationen werden also in Form einer Ressource abstrahiert und die Ressource 113 00:08:06,810 --> 00:08:12,475 wird durch Angabe einer URL identifiziert. 114 00:08:12,475 --> 00:08:18,395 So können alle Informationen, die gekapselt und zur Verfügung gestellt 115 00:08:18,395 --> 00:08:20,720 werden können, als Ressource identifiziert werden. 116 00:08:20,720 --> 00:08:26,980 Eine Information wie das aktuelle Wetter in Hong Kong könnte eine Ressource sein, 117 00:08:26,980 --> 00:08:29,345 ein Bild könnte eine Ressource sein, 118 00:08:29,345 --> 00:08:33,985 eine Aktienkurs-Information könnte eine Ressource sein und so weiter. 119 00:08:33,985 --> 00:08:38,920 Was auch immer Sie als eine Information definieren, an der ein Kunde interessiert sein könnte, 120 00:08:38,920 --> 00:08:41,430 kann als Ressource identifiziert werden. 121 00:08:41,430 --> 00:08:44,045 Sie können sogar Ressourcen als Sammlung von 122 00:08:44,045 --> 00:08:48,740 Ressourcen behandeln, die der Server an den Client senden kann. 123 00:08:48,740 --> 00:08:54,145 Ein Beispiel dafür, wie Sie Ressourcen benennen, wird hier veranschaulicht. 124 00:08:54,145 --> 00:08:57,740 Daher verwenden wir URIs, um die Quelle zu identifizieren. 125 00:08:57,740 --> 00:09:03,355 Ein schnelles Lesen dieser Spezifikation oder der URIs hier 126 00:09:03,355 --> 00:09:10,460 ermöglicht es Ihnen leicht zu verstehen, worauf wir mit diesen URIs verweisen. 127 00:09:10,460 --> 00:09:14,420 So, zum Beispiel, etwas, das mit Gerichten/ endet, gehen 128 00:09:14,420 --> 00:09:19,315 Sie automatisch davon aus, dass sich dies auf eine Sammlung von Gerichten bezieht. 129 00:09:19,315 --> 00:09:22,795 Aber Gerichte/123 zum Beispiel 130 00:09:22,795 --> 00:09:28,250 könnte Gericht Nummer 123 in diesem Fall bedeuten und so weiter. 131 00:09:28,250 --> 00:09:31,320 So ist es sehr einfach zu speichern und Sie können 132 00:09:31,320 --> 00:09:34,650 eine Sammlung von Ressourcen angeben und in der Lage sein, 133 00:09:34,650 --> 00:09:38,815 sie als Sammlung zu identifizieren und dann als Sammlung herunterladen, oder Sie können 134 00:09:38,815 --> 00:09:43,965 eine einzelne Ressource identifizieren und sagen, dass Sie diese bestimmte Ressource wollen. 135 00:09:43,965 --> 00:09:50,395 Nun können diese Ressourcen in einer Hierarchie der Spezifikation dieses URI organisiert werden. 136 00:09:50,395 --> 00:09:52,740 Wenn Sie also den Pfad durchlaufen, 137 00:09:52,740 --> 00:09:58,325 gehen Sie vom allgemeineren zur spezifischeren Ressource. 138 00:09:58,325 --> 00:10:02,110 Diese Verzeichnisstruktur ermöglicht es Ihnen, die Ressourcen 139 00:10:02,110 --> 00:10:07,780 , die Sie auf Ihrer Serverseite verwenden oder bereitstellen, sehr einfach zu identifizieren. 140 00:10:07,780 --> 00:10:11,585 Der zweite Teil der REST-API sind die Verben. 141 00:10:11,585 --> 00:10:16,760 Insbesondere interessieren wir uns für die vier Verben von HTTP die GET, 142 00:10:16,760 --> 00:10:19,140 PUT, POST und DELETE. 143 00:10:19,140 --> 00:10:24,410 In diesem Fall werden diese Verben in Aktionen zugeordnet, die wir 144 00:10:24,410 --> 00:10:29,755 auf der Ressource, auf der Serverseite ausgeführt werden wollen. 145 00:10:29,755 --> 00:10:34,170 Ein GET würde bedeuten, dass Sie einen Lesevorgang für die Ressource ausführen möchten. 146 00:10:34,170 --> 00:10:43,480 Das bedeutet, dass ein Client, der eine GET-Anfrage sendet, an den Server anzeigt, 147 00:10:43,480 --> 00:10:46,380 dass er eine Darstellung dieser Ressource von der Serverseite zur Client-Seite erhalten möchte. 148 00:10:46,380 --> 00:10:48,960 Ein POST bedeutet, dass Sie 149 00:10:48,960 --> 00:10:52,755 eine neue Ressource erstellen möchten und dann die Details der Ressource 150 00:10:52,755 --> 00:10:55,795 in der Darstellung angeben, die für die 151 00:10:55,795 --> 00:10:59,799 Angabe der Ressource verwendet wird, und diese Informationen dann an die serverseitige Seite senden, 152 00:10:59,799 --> 00:11:03,285 damit der Server diese Ressource in Ihrem Namen erstellt. 153 00:11:03,285 --> 00:11:06,370 Ein PUT wäre eine Änderung von Ressourcen und 154 00:11:06,370 --> 00:11:09,955 eine DELETE, wie Sie erwarten würden, ist das Löschen der Ressourcen. 155 00:11:09,955 --> 00:11:15,110 Wie Sie sehen können, 156 00:11:15,110 --> 00:11:19,180 werden die vier Verben GET, POST, PUT und DELETE den vier CRUD-Operationen zugeordnet, die Sie in 157 00:11:19,180 --> 00:11:24,035 einer Datenbank ausführen können, die diese Ressourcen auf der Serverseite speichert, die 158 00:11:24,035 --> 00:11:27,815 READ, CREATE, UPDATE und DELETE. 159 00:11:27,815 --> 00:11:33,760 Ausführend ist das HTTP GET eine Möglichkeit, anzugeben, dass 160 00:11:33,760 --> 00:11:36,950 die Informationen oder die Darstellung 161 00:11:36,950 --> 00:11:40,235 der Ressource vom Server an den Client zurückgegeben werden sollen. 162 00:11:40,235 --> 00:11:43,890 Wenn Sie also eine GET-Anforderung an einen REST-API-Endpunkt ausgeben, 163 00:11:43,890 --> 00:11:49,130 fragen Sie entweder nach einer Sammlung von Ressourcen, die durch 164 00:11:49,130 --> 00:11:57,530 URI dargestellt werden, oder einer bestimmten Ressource, die durch die ID dieser bestimmten Ressource identifiziert wird, 165 00:11:57,530 --> 00:11:59,490 die in der URL angegeben ist. 166 00:11:59,490 --> 00:12:01,000 Also, wie Sie in diesem Beispiel sehen, 167 00:12:01,000 --> 00:12:03,800 wenn Sie sagen, Gerichte/452, 168 00:12:03,800 --> 00:12:08,320 wollen Sie sagen, dass Gericht Nummer 452 mit 169 00:12:08,320 --> 00:12:13,075 der ID 452 an die Client-Seite zurückgegeben werden sollte. 170 00:12:13,075 --> 00:12:18,175 In ähnlicher Weise wird die POST-Operation, wie wir sahen, verwendet, um die Ressource zu erstellen. 171 00:12:18,175 --> 00:12:20,065 Wenn Sie also die Ressource erstellen, 172 00:12:20,065 --> 00:12:26,920 wird der Inhalt der Beschreibung der Ressource in Form einer JSON-Repräsentation oder 173 00:12:26,920 --> 00:12:29,790 einer XML-Repräsentation vorliegen, die im 174 00:12:29,790 --> 00:12:34,075 Hauptteil der Anforderungsnachricht enthalten wird, die an die serverseitige Seite gesendet wird. 175 00:12:34,075 --> 00:12:38,095 Daher erwartet ein POST-Vorgang eine Darstellung 176 00:12:38,095 --> 00:12:42,870 der Ressource im JSON- oder XML-Format im Hauptteil der Anforderungsnachricht. 177 00:12:42,870 --> 00:12:44,890 Wenn der Server diese Anforderungsnachricht empfängt, 178 00:12:44,890 --> 00:12:49,960 erstellt der Server diese Ressource auf der Serverseite und gibt dann 179 00:12:49,960 --> 00:12:58,030 entweder eine Konformation oder einen Fehler zurück, der darauf hinweist, dass die Ressourcenerstellung fehlgeschlagen ist. 180 00:12:58,030 --> 00:13:02,725 In ähnlicher Weise wird eine PUT-Operation verwendet, um eine Ressource zu aktualisieren. 181 00:13:02,725 --> 00:13:06,315 Wenn Sie eine PUT-Operation für eine Ressource auf der Serverseite ausführen, 182 00:13:06,315 --> 00:13:10,200 können Sie die Änderung 183 00:13:10,200 --> 00:13:15,470 entweder zurücksenden, indem Sie nur die Teiländerung angeben, die Sie auf 184 00:13:15,470 --> 00:13:20,200 die bestimmte Ressource im Textkörper der Antwortnachricht auswirken möchten, oder Sie können 185 00:13:20,200 --> 00:13:25,345 die vollständige Darstellung der -Ressource im Nachrichtentext. 186 00:13:25,345 --> 00:13:28,705 Abhängig von der Anordnung zwischen dem Client und dem Server 187 00:13:28,705 --> 00:13:37,195 erwartet der Server, dass die Informationen im Textkörper der Anforderungsnachricht weitergegeben werden. 188 00:13:37,195 --> 00:13:42,600 Ein DELETE-Vorgang, wie Sie erwarten, löscht die vorhandene Ressource. 189 00:13:42,600 --> 00:13:45,460 Nun, in diesem speziellen Fall, 190 00:13:45,460 --> 00:13:49,670 wäre natürlich eine DELETE-Operation idempotent, denn wenn Sie 191 00:13:49,670 --> 00:13:54,145 versuchen, eine Ressource zu löschen und die Ressource existiert, wird sie gelöscht. 192 00:13:54,145 --> 00:13:56,445 Wenn Sie versuchen, eine nicht vorhandene Ressource zu löschen, 193 00:13:56,445 --> 00:14:01,220 führt dies zu keiner weiteren Änderung auf der Serverseite, 194 00:14:01,220 --> 00:14:06,165 außer dass der Server mit einer Fehlermeldung antwortet, die besagt, dass die Ressource nicht existiert. 195 00:14:06,165 --> 00:14:12,530 Dennoch ist DELETE in diesem Fall ein Beispiel für eine idempotente Operation. 196 00:14:12,530 --> 00:14:16,510 In ähnlicher Weise ist die GET-Operation auch eine idempotente Operation, da sie 197 00:14:16,510 --> 00:14:20,885 keine Änderungen an der Ressource auf der Serverseite vornimmt. 198 00:14:20,885 --> 00:14:26,925 POST und PUT werden natürlich die Ressource auf der Serverseite ändern, 199 00:14:26,925 --> 00:14:31,940 entweder eine neue Ressource erstellen oder eine vorhandene Ressource auf der Serverseite ändern. 200 00:14:31,940 --> 00:14:34,060 Natürlich sind die Repräsentationen, 201 00:14:34,060 --> 00:14:36,730 wie ich betont habe, 202 00:14:36,730 --> 00:14:43,980 die beiden gängigen Formate für die Darstellung entweder JSON oder XML. 203 00:14:43,980 --> 00:14:47,105 Der letzte Teil, den wir betonen müssen 204 00:14:47,105 --> 00:14:51,060 , ist, dass serverseitig völlig zustandslos sein sollte, 205 00:14:51,060 --> 00:14:53,640 was bedeutet, dass die serverseitige Seite 206 00:14:53,640 --> 00:14:59,145 den Clientstatus nicht verfolgt, denn wenn der Server den Clientstatus verfolgen muss, 207 00:14:59,145 --> 00:15:00,935 ist er nicht skalierbar. 208 00:15:00,935 --> 00:15:05,160 Für eine skalierbare Implementierung der serverseitigen, 209 00:15:05,160 --> 00:15:09,620 verwenden Sie normalerweise einen zustandslosen Server auf der Serverseite. 210 00:15:09,620 --> 00:15:12,910 Daher wird jede Anforderung, die der Client an den Server sendet, 211 00:15:12,910 --> 00:15:16,490 als unabhängige Anforderung behandelt und 212 00:15:16,490 --> 00:15:20,330 spiegelt nicht auf vorherige Anforderungen wider 213 00:15:20,330 --> 00:15:24,685 , die bereits vom Server von diesem bestimmten Client verarbeitet wurden. 214 00:15:24,685 --> 00:15:29,605 Es liegt also in der Verantwortung des Kunden, seinen eigenen Zustand zu verfolgen, 215 00:15:29,605 --> 00:15:34,635 entweder in Form von Cookies oder mit einer clientseitigen Datenbank, 216 00:15:34,635 --> 00:15:37,435 was auch immer geeignet ist. 217 00:15:37,435 --> 00:15:41,790 Nun ist dieser Ansatz, bei dem der Client seinen eigenen Status verfolgt, 218 00:15:41,790 --> 00:15:44,815 viel skalierbarer, da jeder einzelne Client 219 00:15:44,815 --> 00:15:48,240 für die Verfolgung seines eigenen Status verantwortlich ist. 220 00:15:48,240 --> 00:15:53,840 Hier hilft uns das clientseitige MVC-Setup in dieser Hinsicht. 221 00:15:53,840 --> 00:15:57,440 Schließlich sind wir noch nicht mit REST fertig. 222 00:15:57,440 --> 00:16:04,145 Wir werden mehr von REST in den Übungen sehen, die in dieser speziellen Lektion folgen, 223 00:16:04,145 --> 00:16:12,310 und dann werden wir auch weitere Details zur REST-Verwendung im Rest dieses Kurses sehen.