1
00:00:00,000 --> 00:00:03,979
(MUSIK)

2
00:00:03,979 --> 00:00:06,750
Lass mich dich kurz ausruhen.

3
00:00:08,010 --> 00:00:09,480
Hab dich da!

4
00:00:09,480 --> 00:00:10,800
Was ich sagen wollte, war,

5
00:00:10,800 --> 00:00:16,860
lassen Sie mich Ihnen einen kurzen Überblick über den repräsentativen Staatstransfer geben.

6
00:00:16,860 --> 00:00:18,670
Was genau ist Ruhe?

7
00:00:18,670 --> 00:00:22,900
Wie nutzen wir es in unserer Winkelapplikation und

8
00:00:22,900 --> 00:00:26,450
wie nutzen wir dies für die Kommunikation mit dem Server?

9
00:00:26,450 --> 00:00:30,050
Wie unterstützt ein Server die REST-API und

10
00:00:30,050 --> 00:00:35,060
wie greifen wir von unserer Angular-Anwendung auf die REST-API zu?

11
00:00:35,060 --> 00:00:39,170
Lassen Sie uns darüber in dieser Lektion ein wenig mehr sprechen.

12
00:00:39,170 --> 00:00:43,880
In diesem speziellen Vortrag werde ich Ihnen einen kurzen Überblick über REST geben.

13
00:00:46,010 --> 00:00:50,620
Ich bin sicher, dass Sie den Begriff Web Services

14
00:00:50,620 --> 00:00:53,990
in der IT-Welt sehr oft gehört haben.

15
00:00:53,990 --> 00:00:56,160
Was genau sind Webdienste?

16
00:00:56,160 --> 00:01:01,980
Web-Services sind eine Möglichkeit, Systeme zu entwerfen, um die Interoperabilität zwischen

17
00:01:01,980 --> 00:01:07,920
Systemen zu unterstützen, die über ein Netzwerk verbunden sind, wie das Internet, wie wir heute sehen.

18
00:01:07,920 --> 00:01:11,830
Dies ist, was wir als serviceorientierte Architektur bezeichnen.

19
00:01:11,830 --> 00:01:18,100
Nun, was das bedeutet, ist, dass Sie eine standardisierte Methode für zwei Computer

20
00:01:18,100 --> 00:01:22,190
, die mit dem Internet verbunden sind, bieten, um miteinander kommunizieren zu können.

21
00:01:23,670 --> 00:01:26,970
Ihre Anwendungslayoutebene für

22
00:01:26,970 --> 00:01:30,920
Datenbankanwendungen, die offene Standards verwenden.

23
00:01:30,920 --> 00:01:34,660
Ich habe dort viel Jargon benutzt.

24
00:01:35,710 --> 00:01:37,420
Lassen Sie uns versuchen, sie zusammenzureißen und

25
00:01:37,420 --> 00:01:41,640
ein wenig darüber in diesem Vortrag zu verstehen.

26
00:01:42,640 --> 00:01:49,570
Zwei gängige Ansätze, die zur Unterstützung von Webdiensten verwendet werden, sind SOAP,

27
00:01:49,570 --> 00:01:54,720
die einfachen Objektzugriffsprotokoll-basierten

28
00:01:54,720 --> 00:01:58,820
Webdienste, die die Beschreibungssprache für Webdienste verwenden, um

29
00:01:58,820 --> 00:02:03,150
anzugeben, wie die beiden Endpunkte miteinander kommunizieren.

30
00:02:03,150 --> 00:02:07,667
Und in der Regel basiert Soap auf der Verwendung von XML als

31
00:02:07,667 --> 00:02:12,240
Format für die Nachrichten, die zwischen den beiden Endpunkten ausgetauscht werden.

32
00:02:13,990 --> 00:02:19,910
Der Präsentationsstatus Transfer oder Rest verwendet auch Webstandards, aber der Austausch

33
00:02:19,910 --> 00:02:24,020
von Daten zwischen den beiden Endpunkten könnte entweder XML oder zunehmend sein.

34
00:02:25,150 --> 00:02:28,960
Verwenden von JSON als Format

35
00:02:28,960 --> 00:02:34,960
Der REST-Weg der Interoperabilität ist einfacher im Vergleich zu SOAP, und

36
00:02:34,960 --> 00:02:42,940
daher hat REST eine viel breitere Bereitstellung in den übrig gebliebenen Webdiensten gefunden.

37
00:02:43,950 --> 00:02:49,230
In der Regel wird die Client-Server-Kommunikation mithilfe von REST erleichtert,

38
00:02:49,230 --> 00:02:54,830
wobei der Server die REST-API unterstützt und der Client dann seine

39
00:02:54,830 --> 00:03:01,000
REST-API-Endpunkte aufrufen kann, um Informationen zu erhalten oder Informationen auf den Server hochzuladen.

40
00:03:01,000 --> 00:03:05,910
Wieder habe ich das Wort erwähnt, rufen Sie diesen REST-API-Endpunkt auf.

41
00:03:05,910 --> 00:03:09,290
Das sind also ein paar Begriffe, die ich benutzt habe.

42
00:03:09,290 --> 00:03:12,460
Lassen Sie uns einige davon in den nächsten Folien klären.

43
00:03:13,790 --> 00:03:18,710
Repräsentative Zustandsübertragung ist ein Stil der Software-Architektur, die

44
00:03:18,710 --> 00:03:23,360
speziell für verteilte Hypermedia über das World Wide Web entwickelt wurde.

45
00:03:24,770 --> 00:03:30,810
Nun wurde dies zuerst von Roy Fielding in seiner Dissertation vorgestellt.

46
00:03:30,810 --> 00:03:33,750
Nun, das ist eine dieser Doktorarbeiten, die tatsächlich

47
00:03:33,750 --> 00:03:35,970
etwas Nützliches für die Welt produziert hat.

48
00:03:35,970 --> 00:03:44,250
Das hat also wieder viel Traktion in der Web-Services-Welt gefunden.

49
00:03:44,250 --> 00:03:50,410
Dies ist eine Sammlung von Netzwerkprinzipien, die beschreiben, wie Ressourcen

50
00:03:51,630 --> 00:03:57,060
auf Servern verfügbar gemacht werden können. Auf diese Ressourcen kann von Clients aus zugegriffen werden,

51
00:03:57,060 --> 00:04:02,520
indem die Ressourcen mithilfe von REST-API-Endpunkten identifiziert werden.

52
00:04:02,520 --> 00:04:07,150
Innerhalb von Representational State Transfer gibt es vier grundlegende Gestaltungsprinzipien.

53
00:04:07,150 --> 00:04:11,310
In erster Linie basiert REST auf dem HTTP-Protokoll.

54
00:04:11,310 --> 00:04:17,800
So verwendet es alle HTTP-Methoden, die wir bereits in der vorherigen Lektion gesehen haben.

55
00:04:17,800 --> 00:04:22,750
Zweitens ist REST so konzipiert, dass er zustandslos ist, was bedeutet, dass der Server

56
00:04:22,750 --> 00:04:27,350
nach Abschluss der Kommunikation keine Informationen über den Status speichert.

57
00:04:27,350 --> 00:04:31,850
Wenn also ein Server die Anforderung empfängt, antwortet der Server und

58
00:04:31,850 --> 00:04:37,020
danach erinnert er sich an nichts mehr über diese

59
00:04:37,020 --> 00:04:39,730
Konversation zwischen dem Client und dem Server.

60
00:04:39,730 --> 00:04:44,620
Drittens besteht die REST-Methode zur Bereitstellung von Ressourcen darin,

61
00:04:44,620 --> 00:04:49,990
eine Verzeichnisstruktur wie URLs einheitliche Ressourcenlocator-URLs verfügbar zu machen.

62
00:04:51,090 --> 00:04:57,210
Und viertens ist ihr Format für den Datenaustausch typischerweise JSON oder

63
00:04:57,210 --> 00:05:02,360
XML oder beides, die mit REST unterstützt werden können.

64
00:05:02,360 --> 00:05:07,940
Eine der Motivationen für den Anstieg, der REST als eine Möglichkeit zur Unterstützung von

65
00:05:07,940 --> 00:05:14,060
Webdiensten vorschlägt, ist, dass es all das erfasst, was gut von all dem World Wide Web ist.

66
00:05:14,060 --> 00:05:17,130
Und das machte das Word Wide Web erfolgreich.

67
00:05:17,130 --> 00:05:23,240
Die Verwendung von Uniform Resource Indicators oder Uniform Resource Locators, URLs, mit

68
00:05:23,240 --> 00:05:28,660
denen Sie Ressourcen adressieren können, indem Sie sie als URL angeben,

69
00:05:28,660 --> 00:05:35,370
wobei die zweite ein Protokoll ist, das über das HTTP-Protokoll verfügt.

70
00:05:35,370 --> 00:05:40,820
HTTP hat bereits eine breite Bereitstellung im Internet gefunden.

71
00:05:40,820 --> 00:05:46,370
Drittens, der Anforderungsantwort Zyklus, für den HTTP bekannt ist.

72
00:05:46,370 --> 00:05:51,850
Sie senden also eine Anfrage, der Server empfängt Ihre Anfrage, verarbeitet die Anfrage,

73
00:05:51,850 --> 00:05:57,835
sendet die Antwort an die Anfrage, und dieser Client empfängt die Antwort,

74
00:05:57,835 --> 00:06:00,845
wirkt darauf und generiert möglicherweise weitere Anforderungen.

75
00:06:00,845 --> 00:06:06,815
Also, dieser Ansatz des Request Response Zyklus ist sehr gut etabliert mit HTTP

76
00:06:06,815 --> 00:06:14,740
und dem weltweiten Web The HTTP-Protokoll, wie wir zuvor gesehen haben,

77
00:06:14,740 --> 00:06:19,670
werden wir alle verschiedenen Verben verwenden, die HTTP bietet.

78
00:06:19,670 --> 00:06:23,120
Insbesondere das Tor setzen Post löschen.

79
00:06:23,120 --> 00:06:26,730
Für die Möglichkeit, Operationen anzugeben, die

80
00:06:26,730 --> 00:06:29,680
auf Ressourcen ausgeführt werden, die auf der Serverseite gespeichert sind.

81
00:06:29,680 --> 00:06:34,320
Wenn Sie beispielsweise eine HTTP GET-Anforderung ausführen, fragen Sie nach

82
00:06:34,320 --> 00:06:36,180
dem Server, um die Quelle zurückzugeben.

83
00:06:36,180 --> 00:06:41,410
Wenn Sie eine POST-Anforderung ausführen, bitten Sie den Server, eine neue Ressource zu erstellen.

84
00:06:41,410 --> 00:06:44,330
Wenn Sie eine PUT-Anforderung ausführen, bitten Sie den Server,

85
00:06:44,330 --> 00:06:48,780
eine vorhandene Ressource zu aktualisieren, und wenn Sie eine Löschanforderung ausgeben, bitten Sie

86
00:06:48,780 --> 00:06:54,210
den Server, die Ressource zu löschen, die durch diese bestimmte URL identifiziert wird.

87
00:06:54,210 --> 00:06:57,890
Außerdem versucht es, die Idempotenz zu bewahren.

88
00:06:57,890 --> 00:07:00,970
Einige Operationen, wenn sie

89
00:07:00,970 --> 00:07:04,370
auch wiederholt ausgeführt werden, verursachen keine Änderung des Zustands.

90
00:07:04,370 --> 00:07:08,160
Einige andere Operationen, wenn Sie sie nacheinander tun,

91
00:07:08,160 --> 00:07:11,170
können sie eine Änderung des Zustands verursachen.

92
00:07:11,170 --> 00:07:14,780
Sie müssen also vorsichtig sein, welche Operationen

93
00:07:14,780 --> 00:07:16,660
ohne schädliche Folgen wiederholt werden können.

94
00:07:16,660 --> 00:07:19,570
Und die müssen sehr sorgfältig gemacht werden.

95
00:07:21,070 --> 00:07:25,530
In der REST-Welt hört man oft Leute, die über Substantive,

96
00:07:25,530 --> 00:07:28,230
Verben und Darstellungen sprechen.

97
00:07:28,230 --> 00:07:34,120
Jetzt werden wir jede dieser Folien in den nächsten Folien ein wenig detaillierter klären.

98
00:07:34,120 --> 00:07:36,720
Substantive, insbesondere, sie sind voll von Ressourcen, und

99
00:07:36,720 --> 00:07:42,580
diese Ressourcen werden in der Regel durch ihre URLs identifiziert, und diese sind nicht eingeschränkt.

100
00:07:42,580 --> 00:07:48,890
Verben sind eingeschränkt und diese angegebenen Aktionen auf die Ressourcen durchgeführt werden.

101
00:07:48,890 --> 00:07:53,200
Und die Präsentationen, wie wir sehen, wenn

102
00:07:53,200 --> 00:07:54,560
die Informationen vom Server zum Client oder

103
00:07:54,560 --> 00:07:58,150
vom Client zum Server übertragen werden müssen, wie Sie die Informationen codieren.

104
00:07:58,150 --> 00:08:02,840
In der Regel entweder mit JSON oder mit XML.

105
00:08:02,840 --> 00:08:08,150
Ressource ist die Schlüsselabstraktion, die REST umgeht

106
00:08:08,150 --> 00:08:11,787
, so dass Informationen in der Ressource abstrahiert werden.

107
00:08:11,787 --> 00:08:18,690
Und die Ressource wird identifiziert, indem sie mithilfe eines URI angegeben wird.

108
00:08:18,690 --> 00:08:23,040
So können alle Informationen, die gekapselt und

109
00:08:23,040 --> 00:08:26,980
zur Verfügung gestellt werden können, als Ressource identifiziert werden.

110
00:08:26,980 --> 00:08:33,145
Eine Information wie das aktuelle Wetter in Hong Kong könnte eine Ressource sein,

111
00:08:33,145 --> 00:08:35,465
ein Bild könnte eine Ressource sein.

112
00:08:35,465 --> 00:08:39,915
Eine Aktienkurs-Information könnte eine Ressource sein, und so weiter.

113
00:08:39,915 --> 00:08:43,905
Was auch immer Sie als eine Information definieren, an der ein Kunde

114
00:08:43,905 --> 00:08:47,515
interessiert sein könnte, kann als Ressource identifiziert werden.

115
00:08:47,515 --> 00:08:50,965
Sie können sogar Ressourcen als Sammlung von Ressourcen behandeln

116
00:08:50,965 --> 00:08:55,070
, die dieser Server möglicherweise an diesen Client sendet.

117
00:08:55,070 --> 00:09:00,380
Ein Beispiel dafür, wie Sie Ressourcen benennen, wird hier veranschaulicht.

118
00:09:00,380 --> 00:09:03,898
Daher verwenden wir URIs, um die Quelle zu identifizieren.

119
00:09:03,898 --> 00:09:09,575
Ein schnelles Lesen der Spezifikation oder der URLs hier

120
00:09:09,575 --> 00:09:16,525
ermöglicht Ihnen leicht zu verstehen, worauf wir verweisen, indem Sie diese URLs verwenden.

121
00:09:16,525 --> 00:09:19,675
So zum Beispiel, etwas, das mit Gerichten/ endet, gehen

122
00:09:19,675 --> 00:09:25,495
Sie automatisch davon aus, dass sich dies auf eine Sammlung von Gerichten bezieht.

123
00:09:25,495 --> 00:09:28,909
Wie Gerichte/123 zum Beispiel

124
00:09:28,909 --> 00:09:34,150
könnte Gericht Nummer 123 bedeuten, in diesem Fall und so weiter.

125
00:09:34,150 --> 00:09:39,530
Es ist also sehr einfach zu sagen, dass Sie eine Sammlung von Ressourcen angeben und in der

126
00:09:39,530 --> 00:09:43,800
Lage sein können, sie als Sammlung zu identifizieren und sie dann als Sammlung herunterzuladen.

127
00:09:43,800 --> 00:09:46,960
Oder Sie können eine einzelne Ressource identifizieren und

128
00:09:46,960 --> 00:09:50,070
sagen, dass Sie diese bestimmte Ressource möchten.

129
00:09:50,070 --> 00:09:53,378
Jetzt können diese Ressourcen in einer Hierarchie organisiert werden

130
00:09:53,378 --> 00:09:56,500
, die Spezifikation dieses URI.

131
00:09:56,500 --> 00:09:58,860
Wenn Sie also den Pfad durchlaufen,

132
00:09:58,860 --> 00:10:04,460
gehen Sie von der allgemeineren zu der spezifischeren Ressource.

133
00:10:04,460 --> 00:10:08,260
Diese Verzeichnisstruktur ermöglicht es Ihnen, die Ressourcen, die

134
00:10:09,320 --> 00:10:14,170
Sie von Ihrer Service-Site bereitstellen, sehr einfach zu identifizieren.

135
00:10:14,170 --> 00:10:17,970
Der zweite Teil der REST-API sind die Wörter.

136
00:10:17,970 --> 00:10:22,150
Insbesondere interessieren wir uns für die 4 Verben von HTTP zu bekommen, zu

137
00:10:22,150 --> 00:10:25,320
setzen, zu posten und zu löschen.

138
00:10:25,320 --> 00:10:30,310
In diesem Fall werden diese Verben Nickerchen auf Aktionen, die wir

139
00:10:30,310 --> 00:10:36,165
auf der Ressource auf der Serverseite ausgeführt werden wollen.

140
00:10:36,165 --> 00:10:40,760
GetT würde bedeuten, dass Sie einen Lesevorgang für die Ressource ausführen möchten, was bedeutet,

141
00:10:40,760 --> 00:10:46,550
dass ein Client, der eine Get-Anforderung sendet, dem Server angibt,

142
00:10:46,550 --> 00:10:52,710
dass er diese Präsentation der Datenquelle vom Serverstandort zum Clientstandort abrufen möchte.

143
00:10:52,710 --> 00:10:56,770
POST bedeutet, dass Sie eine neue Ressource erstellen möchten und dann werden Sie es tun.

144
00:10:56,770 --> 00:11:01,700
Geben Sie die Details der Ressource in der Darstellung an, wird jedoch für

145
00:11:01,700 --> 00:11:02,850
die Angabe der Ressource verwendet.

146
00:11:02,850 --> 00:11:05,900
Dann senden Sie die Informationen an die Serverseite,

147
00:11:05,900 --> 00:11:09,590
damit der Server die Ressource in Ihrem Namen erstellt.

148
00:11:09,590 --> 00:11:12,310
Ein PUT wäre die Änderung von Ressourcen, und

149
00:11:12,310 --> 00:11:16,030
Löschen, wie Sie es erwarten würden, ist das Löschen der Quellen.

150
00:11:16,030 --> 00:11:20,550
Wie Sie sehen können,

151
00:11:20,550 --> 00:11:25,670
werden die vier Verben get, post, put und delete den vier CRUD-Operationen zugeordnet, die Sie in

152
00:11:25,670 --> 00:11:30,140
einer Datenbank ausführen können, die diese Ressourcen auf der Serverseite speichert.

153
00:11:30,140 --> 00:11:34,130
Die Lese-, Erstellungs-, Aktualisierungs- und Löschvorgänge

154
00:11:34,130 --> 00:11:39,140
Ausführend, ist das HTTP GET eine Möglichkeit der Angabe.

155
00:11:39,140 --> 00:11:43,560
Sie möchten, dass die Informationen oder ihre Präsentation der Ressource

156
00:11:43,560 --> 00:11:46,280
vom Serverstandort an den Client zurückgegeben werden.

157
00:11:46,280 --> 00:11:49,980
Wenn Sie also eine GET-Anforderung an einen REST-API-Endpunkt ausgeben.

158
00:11:49,980 --> 00:11:54,370
Sie fragen entweder nach einer Sammlung von Ressourcen, die von

159
00:11:55,890 --> 00:12:01,790
Uri präsentiert werden, oder einer bestimmten Ressource, die durch die ID dieser

160
00:12:01,790 --> 00:12:06,950
bestimmten Ressourcen identifiziert wird, die in der URL angegeben ist, so wie Sie in diesem Beispiel sehen,

161
00:12:06,950 --> 00:12:13,090
wenn Sie Geschirr/452, Sie wollen sagen, dass Gericht Nummer 452,

162
00:12:13,090 --> 00:12:16,950
mit der id 452 sollte an die Client-Seite zurückgegeben werden.

163
00:12:19,370 --> 00:12:24,210
In ähnlicher Weise wird die Post-Operation, wie wir gesehen haben, verwendet, um die Ressource zu erstellen.

164
00:12:24,210 --> 00:12:29,940
Wenn Sie also die Ressource erstellen,

165
00:12:29,940 --> 00:12:34,830
wird der Inhalt der Beschreibung der Ressource in Form einer JSON-Darstellung oder einer XML-Darstellung vorliegen, und dies würde

166
00:12:34,830 --> 00:12:40,220
im Hauptteil der Anforderungsnachricht enthalten, die an die Serverseite gesendet wird.

167
00:12:40,220 --> 00:12:43,900
Daher erwartet eine Post-Operation eine Darstellung

168
00:12:43,900 --> 00:12:49,040
der Ressource im JSON- oder XML-Format im Textkörper der Anforderungsnachricht.

169
00:12:49,040 --> 00:12:53,250
Und der Server erhält eine solche Anforderungsnachricht, der Server erstellt diese

170
00:12:53,250 --> 00:12:58,440
Ressource auf der Serverseite und gibt dann entweder eine Bestätigung oder

171
00:12:58,440 --> 00:13:04,390
einen Fehler zurück, um anzuzeigen, dass die Ressourcenerstellung fehlgeschlagen ist.

172
00:13:04,390 --> 00:13:08,820
In ähnlicher Weise hat es den Betrieb einfach verwendet, um eine Ressource zu aktualisieren.

173
00:13:08,820 --> 00:13:14,630
Wenn Sie eine PUT-Operation auf einer Ressource auf der Serverseite ausführen, können Sie

174
00:13:14,630 --> 00:13:19,630
die Änderung entweder zurücksenden, indem Sie nur die teilweise Änderung angeben

175
00:13:19,630 --> 00:13:25,450
, die Sie auf die bestimmte Ressource im Textkörper der Antwortnachricht auswirken möchten.

176
00:13:25,450 --> 00:13:29,370
Oder Sie können die vollständige Darstellung der Ressource

177
00:13:29,370 --> 00:13:33,890
im Nachrichtentext senden, abhängig von der Anordnung zwischen dem Client und

178
00:13:33,890 --> 00:13:38,760
dem Server erwartet der Server, dass die Informationen

179
00:13:38,760 --> 00:13:43,320
im Hauptteil der Anforderungsnachricht weitergegeben werden.

180
00:13:43,320 --> 00:13:48,980
DELETE-Vorgang, wie Sie erwarten, löscht die vorhandene Ressource.

181
00:13:48,980 --> 00:13:55,150
Nun in diesem speziellen Fall wäre natürlich ein Löschvorgang, weil,

182
00:13:55,150 --> 00:14:00,220
wenn Sie versuchen, eine Ressource zu löschen und die Ressource vorhanden ist, sie gelöscht wird.

183
00:14:00,220 --> 00:14:02,440
Wenn Sie versuchen, eine nicht vorhandene Ressource zu löschen,

184
00:14:02,440 --> 00:14:07,990
führt dies zu keiner weiteren Änderung auf der Serverseite

185
00:14:07,990 --> 00:14:11,808
, außer dass der Server mit einer Fehlermeldung antwortet, die besagt, dass die Ressource nicht existiert.

186
00:14:11,808 --> 00:14:18,700
Aber dennoch, ist ein Beispiel für eine Operation in diesem Fall.

187
00:14:18,700 --> 00:14:22,810
In ähnlicher Weise wird der Get-Vorgang auch ausgeführt, da

188
00:14:22,810 --> 00:14:27,140
keine Änderungen an der Ressource auf der Server-Site vorgenommen werden.

189
00:14:27,140 --> 00:14:32,740
Post-Eingabe werden natürlich die Ressource auf der Serverseite ändern.

190
00:14:32,740 --> 00:14:34,770
Sie müssen eine neue Ressource erstellen oder

191
00:14:34,770 --> 00:14:40,050
vorhandene Ressource auf der Serverseite ändern, und natürlich Datenpräsentationen.

192
00:14:40,050 --> 00:14:45,050
Wie ich betont habe, sind die beiden gemeinsamen Fallbacks für die

193
00:14:45,050 --> 00:14:51,570
Darstellung entweder JSON XML, der letzte Teil, den

194
00:14:51,570 --> 00:14:57,140
wir betonen müssen, ist, dass die Serverseite völlig zustandslos sein sollte.

195
00:14:57,140 --> 00:15:01,190
Das bedeutet, dass die Serverseite den Status des Clients nicht verfolgt.

196
00:15:01,190 --> 00:15:07,060
Wenn der Server den Status des Clients verfolgen muss, ist er nicht skalierbar.

197
00:15:07,060 --> 00:15:11,140
Für eine skalierbare Implementierung der Serverseite

198
00:15:11,140 --> 00:15:15,650
verwenden Sie normalerweise einen zustandslosen Server auf der Serverseite.

199
00:15:15,650 --> 00:15:19,580
Wenn also die Anfrage der Clients, die an den Server gesendet werden

200
00:15:19,580 --> 00:15:25,460
, wird als unabhängige Anfrage behandelt und wird nicht auf vorherige

201
00:15:25,460 --> 00:15:30,790
Anforderungen, die bereits vom Server vom jeweiligen Client bearbeitet wurden, reflektiert.

202
00:15:30,790 --> 00:15:35,760
Es liegt also in der Verantwortung des Kunden, seinen eigenen Zustand zu verfolgen.

203
00:15:35,760 --> 00:15:40,770
Entweder in Form von Cookies oder in einer Datenbank der Client-Site.

204
00:15:40,770 --> 00:15:43,780
Was auch immer bedeutet, dass es geeignet ist.

205
00:15:43,780 --> 00:15:48,760
Nun ist dieser Ansatz, bei dem der Client seinen eigenen Status verfolgt, viel skalierbarer,

206
00:15:48,760 --> 00:15:52,880
da Ihr Client für die Verfolgung seines eigenen Status verantwortlich ist.

207
00:15:54,340 --> 00:15:58,880
Und hier hilft uns das clientseitige MVC-Setup in dieser Hinsicht.

208
00:16:00,100 --> 00:16:04,920
Und schließlich sind wir noch nicht mit REST fertig, wir werden mehr von

209
00:16:04,920 --> 00:16:10,280
REST in den Übungen sehen, die in dieser speziellen Lektion folgen.

210
00:16:10,280 --> 00:16:11,563
Und dann

211
00:16:11,563 --> 00:16:17,206
werden wir auch weitere Details zur REST-Verwendung im Rest dieses Kurses sehen.

212
00:16:17,206 --> 00:16:20,509
( MUSIK)