1
00:00:00,000 --> 00:00:03,979
[MUSIQUE]

2
00:00:03,979 --> 00:00:06,750
Laissez-moi vous donner un bref repos.

3
00:00:08,010 --> 00:00:09,480
Vous y a eu !

4
00:00:09,480 --> 00:00:10,800
Ce que je voulais dire était,

5
00:00:10,800 --> 00:00:16,860
laissez-moi vous donner un bref aperçu du transfert d'État représentatif.

6
00:00:16,860 --> 00:00:18,670
Qu'est-ce que le repos ?

7
00:00:18,670 --> 00:00:22,900
Comment l'utilisons-nous dans notre application angulaire et

8
00:00:22,900 --> 00:00:26,450
comment l'utilisons-nous pour communiquer avec le serveur ?

9
00:00:26,450 --> 00:00:30,050
Comment un serveur prend-il en charge l'API REST et

10
00:00:30,050 --> 00:00:35,060
comment accèderons-nous à l'API REST à partir de notre application Angular ?

11
00:00:35,060 --> 00:00:39,170
Parlons un peu plus de cela dans cette leçon.

12
00:00:39,170 --> 00:00:43,880
Dans cette conférence particulière, je vais vous donner un bref aperçu de REST.

13
00:00:46,010 --> 00:00:50,620
Je suis sûr que vous avez souvent entendu le terme Services Web mentionner

14
00:00:50,620 --> 00:00:53,990
dans le monde informatique.

15
00:00:53,990 --> 00:00:56,160
Que sont exactement les services Web ?

16
00:00:56,160 --> 00:01:01,980
Les services Web sont un moyen de concevoir des systèmes qui prennent en charge l'interopérabilité entre les systèmes

17
00:01:01,980 --> 00:01:07,920
connectés sur un réseau, comme l'Internet comme nous le voyons aujourd'hui.

18
00:01:07,920 --> 00:01:11,830
C'est ce que nous appelons une architecture orientée service.

19
00:01:11,830 --> 00:01:18,100
Maintenant, cela signifie que vous fournissez un moyen standardisé pour deux machines

20
00:01:18,100 --> 00:01:22,190
connectées à Internet pour pouvoir communiquer entre elles.

21
00:01:23,670 --> 00:01:26,970
Leur niveau de mise en page d'application pour les applications de base de données

22
00:01:26,970 --> 00:01:30,920
utilisant des standards ouverts.

23
00:01:30,920 --> 00:01:34,660
Maintenant, j'ai utilisé beaucoup de jargon là-bas.

24
00:01:35,710 --> 00:01:37,420
Essayons de les décomposer et

25
00:01:37,420 --> 00:01:41,640
comprendrons un peu chacun de cela dans cette conférence.

26
00:01:42,640 --> 00:01:49,570
Deux approches courantes qui sont utilisées pour prendre en charge les services Web sont SOAP,

27
00:01:49,570 --> 00:01:54,720
les services Web basés sur le protocole d'accès aux objets simples,

28
00:01:54,720 --> 00:01:58,820
qui utilise le langage de description des services Web pour

29
00:01:58,820 --> 00:02:03,150
spécifiant comment les deux points finaux communiquent les uns avec les autres.

30
00:02:03,150 --> 00:02:07,667
Et généralement, soap est basé sur l'utilisation de XML comme

31
00:02:07,667 --> 00:02:12,240
le format des messages échangés entre les deux points de terminaison.

32
00:02:13,990 --> 00:02:19,910
Le transfert d'état de présentation ou le repos utilise également des standards web, mais l'échange

33
00:02:19,910 --> 00:02:24,020
de données entre les deux points de terminaison pourrait être XML ou de plus en plus.

34
00:02:25,150 --> 00:02:28,960
Utilisation de JSON comme format.

35
00:02:28,960 --> 00:02:34,960
La façon REST d'interopérabilité est plus simple que SOAP et

36
00:02:34,960 --> 00:02:42,940
, donc REST a trouvé un déploiement beaucoup plus large dans les services web restés.

37
00:02:43,950 --> 00:02:49,230
Généralement, la communication du serveur client est facilitée à l'aide de REST

38
00:02:49,230 --> 00:02:54,830
où le serveur prend en charge l'API REST et le client peut alors invoquer ses points de terminaison REST API

39
00:02:54,830 --> 00:03:01,000
afin d'obtenir des informations ou de télécharger des informations sur le serveur.

40
00:03:01,000 --> 00:03:05,910
Encore une fois, j'ai mentionné le mot, invoquez ce point de fin de l'API REST.

41
00:03:05,910 --> 00:03:09,290
Ce sont donc quelques termes que j'ai utilisés.

42
00:03:09,290 --> 00:03:12,460
Clarifions certains d'entre eux dans les prochaines diapositives.

43
00:03:13,790 --> 00:03:18,710
Representational state transfer est un style d'architecture logicielle qui

44
00:03:18,710 --> 00:03:23,360
est spécialement conçu pour les hypermédias distribués sur le World Wide Web.

45
00:03:24,770 --> 00:03:30,810
Maintenant cela a été introduit pour la première fois par Roy Fielding dans sa thèse de doctorat.

46
00:03:30,810 --> 00:03:33,750
Maintenant, c'est une de ces thèses de doctorat qui a produit

47
00:03:33,750 --> 00:03:35,970
quelque chose d'utile pour le monde.

48
00:03:35,970 --> 00:03:44,250
Cela a donc retrouvé beaucoup de traction dans le monde des services web.

49
00:03:44,250 --> 00:03:50,410
Il s'agit d'un ensemble de principes réseau qui décrivent comment les ressources peuvent être mises à disposition sur les serveurs, et ces ressources sont accessibles depuis les clients

50
00:03:51,630 --> 00:04:02,520
en identifiant les ressources à l'aide des points de terminaison de l'API REST.

51
00:04:02,520 --> 00:04:07,150
Dans le transfert d'État représentationnel, il y a quatre principes de conception de base.

52
00:04:07,150 --> 00:04:11,310
Tout d'abord, REST est construit sur le protocole HTTP.

53
00:04:11,310 --> 00:04:17,800
Donc, il utilise toutes les méthodes HTTP que nous avons déjà vu dans la leçon précédente.

54
00:04:17,800 --> 00:04:22,750
Deuxièmement, REST est conçu pour être sans état, ce qui signifie que le serveur ne stocke pas

55
00:04:22,750 --> 00:04:27,350
d'informations sur l'état une fois la communication terminée.

56
00:04:27,350 --> 00:04:31,850
Donc, quand un serveur reçoit la requête, le serveur répond et

57
00:04:31,850 --> 00:04:37,020
ensuite, il ne se souvient plus de cette conversation

58
00:04:37,020 --> 00:04:39,730
entre le client et le serveur.

59
00:04:39,730 --> 00:04:44,620
Troisièmement, la façon REST de fournir des ressources est de

60
00:04:44,620 --> 00:04:49,990
exposer une structure de répertoire comme les URL des localisateurs de ressources uniformes.

61
00:04:51,090 --> 00:04:57,210
Et quatrièmement, leur format pour l'échange de données est généralement JSON ou

62
00:04:57,210 --> 00:05:02,360
XML, ou les deux qui peuvent être pris en charge à l'aide de REST.

63
00:05:02,360 --> 00:05:07,940
Une des motivations à la hausse suggérant REST comme un moyen de soutenir les services Web

64
00:05:07,940 --> 00:05:14,060
est qu'il capture tout ce qui est bon de tout le World Wide Web.

65
00:05:14,060 --> 00:05:17,130
Et cela a fait le succès du Word Wide Web.

66
00:05:17,130 --> 00:05:23,240
L'utilisation d'indicateurs de ressources uniformes ou de localisateurs de ressources uniformes, URL,

67
00:05:23,240 --> 00:05:28,660
qui vous permettent d'adresser des ressources en les spécifiant comme URL,

68
00:05:28,660 --> 00:05:35,370
le second étant un protocole qui monte au-dessus du protocole HTTP.

69
00:05:35,370 --> 00:05:40,820
HTTP a déjà trouvé un déploiement étendu sur Internet.

70
00:05:40,820 --> 00:05:46,370
Troisièmement, le cycle de réponse à la demande pour lequel HTTP est bien connu.

71
00:05:46,370 --> 00:05:51,850
Donc vous envoyez une demande, le serveur reçoit votre demande, traite la demande,

72
00:05:51,850 --> 00:05:57,835
envoie la réponse à la demande, et ce client reçoit la réponse,

73
00:05:57,835 --> 00:06:00,845
agit sur cela, et peut générer d'autres demandes.

74
00:06:00,845 --> 00:06:06,815
Donc, cette approche du cycle de réponse de la requête est très bien établie avec HTTP

75
00:06:06,815 --> 00:06:14,740
et le Web mondial Le protocole HTTP comme nous l'avons vu plus tôt,

76
00:06:14,740 --> 00:06:19,670
nous utiliserons tous les différents verbes que HTTP fournit.

77
00:06:19,670 --> 00:06:23,120
Plus précisément, la porte mettre post supprimer.

78
00:06:23,120 --> 00:06:26,730
Pour pouvoir spécifier les opérations à effectuer

79
00:06:26,730 --> 00:06:29,680
sur les ressources stockées côté serveur.

80
00:06:29,680 --> 00:06:34,320
Donc, par exemple, si vous faites une requête HTTP GET, vous demandez

81
00:06:34,320 --> 00:06:36,180
le serveur pour renvoyer la source.

82
00:06:36,180 --> 00:06:41,410
Si vous effectuez une requête POST, vous demandez au serveur de créer une nouvelle ressource.

83
00:06:41,410 --> 00:06:44,330
Si vous effectuez une requête PUT, vous demandez au serveur de mettre à jour

84
00:06:44,330 --> 00:06:48,780
une ressource existante et si vous émettez une demande de suppression, vous demandez

85
00:06:48,780 --> 00:06:54,210
au serveur de supprimer la ressource identifiée par cette URL particulière.

86
00:06:54,210 --> 00:06:57,890
Aussi, il essaie de préserver l'idempotence.

87
00:06:57,890 --> 00:07:00,970
Certaines opérations quand elles sont effectuées

88
00:07:00,970 --> 00:07:04,370
Même à plusieurs reprises ne provoquent aucun changement d'état.

89
00:07:04,370 --> 00:07:08,160
D'autres opérations, si vous les faites successivement,

90
00:07:08,160 --> 00:07:11,170
elles peuvent provoquer un changement d'état.

91
00:07:11,170 --> 00:07:14,780
Donc, vous devez être prudent sur les opérations qui peuvent être répétées sans

92
00:07:14,780 --> 00:07:16,660
aucune conséquence néfaste.

93
00:07:16,660 --> 00:07:19,570
Et ce qui doit être fait très soigneusement.

94
00:07:21,070 --> 00:07:25,530
Dans le monde REST, vous entendez souvent des gens parler de noms, de verbes

95
00:07:25,530 --> 00:07:28,230
et de représentations.

96
00:07:28,230 --> 00:07:34,120
Maintenant, nous allons clarifier chacun de ces éléments un peu plus en détail dans les prochaines diapositives.

97
00:07:34,120 --> 00:07:36,720
Noms, en particulier, ils sont pleins de ressources et

98
00:07:36,720 --> 00:07:42,580
ces ressources sont généralement identifiées par leurs URL et celles-ci sont sans contraintes.

99
00:07:42,580 --> 00:07:48,890
Les verbes sont contraints et ces actions spécifiées doivent être effectuées sur les ressources.

100
00:07:48,890 --> 00:07:53,200
Et les présentations telles que nous voyons quand les informations doivent être transmises de

101
00:07:53,200 --> 00:07:54,560
le serveur au client ou

102
00:07:54,560 --> 00:07:58,150
du client au serveur, comment vous encodez les informations.

103
00:07:58,150 --> 00:08:02,840
Généralement, soit en utilisant JSON, soit en utilisant XML.

104
00:08:02,840 --> 00:08:08,150
Resource est l'abstraction clé que REST travaille autour de sorte que

105
00:08:08,150 --> 00:08:11,787
que les informations sont abstractées dans la ressource.

106
00:08:11,787 --> 00:08:18,690
Et la ressource est identifiée en la spécifiant à l'aide d'un URI.

107
00:08:18,690 --> 00:08:23,040
Ainsi, toute information qui peut être encapsulée et

108
00:08:23,040 --> 00:08:26,980
mise à disposition peut être identifiée comme une ressource.

109
00:08:26,980 --> 00:08:33,145
Une information comme la météo actuelle à Hong Kong pourrait être une ressource,

110
00:08:33,145 --> 00:08:35,465
une image pourrait être une ressource.

111
00:08:35,465 --> 00:08:39,915
Une information sur le cours des actions pourrait être une ressource, etc.

112
00:08:39,915 --> 00:08:43,905
Donc, tout ce que vous définissez comme une information qui peut intéresser un client

113
00:08:43,905 --> 00:08:47,515
, peut être identifié comme une ressource.

114
00:08:47,515 --> 00:08:50,965
Vous pouvez même traiter les ressources en tant que collection de ressources

115
00:08:50,965 --> 00:08:55,070
que ce serveur peut envoyer à ce client.

116
00:08:55,070 --> 00:09:00,380
Un exemple de la façon dont vous nommez les ressources est illustré ici.

117
00:09:00,380 --> 00:09:03,898
Nous utilisons donc des URI pour identifier la source.

118
00:09:03,898 --> 00:09:16,525
Une lecture rapide de la spécification ou des URL ici vous permettra de comprendre facilement ce à quoi nous faisons référence en utilisant ces URL.

119
00:09:16,525 --> 00:09:19,675
Donc, par exemple, quelque chose qui se termine par des plates/,

120
00:09:19,675 --> 00:09:25,495
, vous supposez automatiquement que cela fait référence à une collection de plats.

121
00:09:25,495 --> 00:09:28,909
Comme les plats/123 par exemple,

122
00:09:28,909 --> 00:09:34,150
peut signifier le plat numéro 123, dans ce cas et ainsi de suite.

123
00:09:34,150 --> 00:09:39,530
Il est donc très facile de dire que vous pouvez spécifier une collection de ressources, et

124
00:09:39,530 --> 00:09:43,800
être capable de les identifier comme une collection, puis de les télécharger comme une collection.

125
00:09:43,800 --> 00:09:46,960
Ou bien, vous pouvez identifier une ressource individuelle, et

126
00:09:46,960 --> 00:09:50,070
dit que vous voulez cette ressource particulière.

127
00:09:50,070 --> 00:09:53,378
Maintenant, ces ressources peuvent être organisées dans une hiérarchie

128
00:09:53,378 --> 00:09:56,500
cette spécification de cet URI.

129
00:09:56,500 --> 00:09:58,860
Alors que vous traversez le chemin,

130
00:09:58,860 --> 00:10:04,460
vous passez de la plus générale à la plus spécifique de cette ressource.

131
00:10:04,460 --> 00:10:08,260
Cette structure d'annuaire vous permet d'identifier très facilement les ressources que

132
00:10:09,320 --> 00:10:14,170
vous fournissez à partir de votre site de service.

133
00:10:14,170 --> 00:10:17,970
La deuxième partie de l'API REST sont les mots.

134
00:10:17,970 --> 00:10:22,150
En particulier, nous sommes intéressés par les 4 verbes de HTTP pour obtenir,

135
00:10:22,150 --> 00:10:25,320
mettre, poster et supprimer.

136
00:10:25,320 --> 00:10:30,310
Dans ce cas, ces verbes feront la sieste des actions que nous

137
00:10:30,310 --> 00:10:36,165
voulons effectuer sur la ressource côté serveur.

138
00:10:36,165 --> 00:10:40,760
GetT signifie que vous voulez effectuer une opération de lecture sur la ressource, ce qui signifie

139
00:10:40,760 --> 00:10:46,550
qu'un client qui envoie une requête get indique au serveur qu'il souhaite

140
00:10:46,550 --> 00:10:52,710
obtenir cette présentation de la source de données du site serveur vers le site client.

141
00:10:52,710 --> 00:10:56,770
POST signifie que vous voulez créer une nouvelle ressource et alors vous le ferez.

142
00:10:56,770 --> 00:11:01,700
Spécifiez les détails de la ressource dans la représentation, mais est utilisé pour

143
00:11:01,700 --> 00:11:02,850
spécifiant la ressource.

144
00:11:02,850 --> 00:11:05,900
Ensuite, envoyez les informations sur le côté serveur, afin

145
00:11:05,900 --> 00:11:09,590
que le serveur crée la ressource en votre nom.

146
00:11:09,590 --> 00:11:12,310
Un PUT serait une modification des ressources, et

147
00:11:12,310 --> 00:11:16,030
delete, comme vous pouvez vous y attendre, est la suppression des sources.

148
00:11:16,030 --> 00:11:20,550
Donc, comme vous pouvez le voir les quatre verbes obtenir, poster, mettre et

149
00:11:20,550 --> 00:11:25,670
delete sont mappés dans les quatre opérations CRUD que vous pouvez effectuer

150
00:11:25,670 --> 00:11:30,140
sur une base de données qui stocke ces ressources côté serveur.

151
00:11:30,140 --> 00:11:34,130
Les opérations de lecture, de création, de mise à jour et de suppression.

152
00:11:34,130 --> 00:11:39,140
En développant plus loin, le HTTP GET est un moyen de spécifier.

153
00:11:39,140 --> 00:11:43,560
Que vous souhaitez que les informations ou leur présentation de la ressource soient

154
00:11:43,560 --> 00:11:46,280
retournées au client à partir du site serveur.

155
00:11:46,280 --> 00:11:49,980
Donc, lorsque vous émettez une requête GET à un point de terminaison de l'API REST.

156
00:11:49,980 --> 00:11:54,370
Vous demandez soit une collection de ressources qui sont présentées par

157
00:11:55,890 --> 00:12:01,790
Uri ou une ressource spécifique qui est identifiée par l'ID de

158
00:12:01,790 --> 00:12:06,950
ces ressources particulières spécifiées dans l'URL de sorte que vous voyez dans cet exemple,

159
00:12:06,950 --> 00:12:13,090
si vous disais/452, vous voulez dire que le numéro de plat 452,

160
00:12:13,090 --> 00:12:16,950
avec l'id 452 doit être retourné au côté client.

161
00:12:19,370 --> 00:12:24,210
De même, l'opération post, comme nous l'avons vu, est utilisée pour créer la ressource.

162
00:12:24,210 --> 00:12:29,940
Ainsi, lorsque vous créez la ressource, le contenu de la description de la ressource serait

163
00:12:29,940 --> 00:12:34,830
sous la forme d'une représentation JSON ou d'une représentation XML, et cela serait

164
00:12:34,830 --> 00:12:40,220
inclus dans le corps du message de requête envoyé au côté serveur.

165
00:12:40,220 --> 00:12:43,900
Donc, une opération de post attend une représentation

166
00:12:43,900 --> 00:12:49,040
de la ressource au format JSON ou XML dans le corps du message de requête.

167
00:12:49,040 --> 00:12:53,250
Et le serveur reçoit un tel message de demande, le serveur crée cette ressource

168
00:12:53,250 --> 00:12:58,440
côté serveur, puis renvoie une confirmation ou

169
00:12:58,440 --> 00:13:04,390
une erreur pour indiquer que la création de la ressource a échoué.

170
00:13:04,390 --> 00:13:08,820
De même, il a mis l'opération facile à utiliser pour mettre à jour une ressource.

171
00:13:08,820 --> 00:13:14,630
Lorsque vous effectuez une opération PUT sur une ressource côté serveur, vous pouvez renvoyer

172
00:13:14,630 --> 00:13:19,630
la modification soit en spécifiant uniquement la modification partielle

173
00:13:19,630 --> 00:13:25,450
que vous souhaitez effectuer sur la ressource particulière dans le corps du message de réponse.

174
00:13:25,450 --> 00:13:29,370
Ou vous pouvez envoyer la représentation complète de la ressource

175
00:13:29,370 --> 00:13:33,890
dans le corps du message, selon l'arrangement entre le client et

176
00:13:33,890 --> 00:13:38,760
le serveur, le serveur attend que les informations soient transmises

177
00:13:38,760 --> 00:13:43,320
dans le corps du message de requête.

178
00:13:43,320 --> 00:13:48,980
DELETE opération comme vous vous attendez supprime la ressource existante.

179
00:13:48,980 --> 00:13:55,150
Maintenant, dans ce cas particulier, bien sûr, une opération de suppression serait parce que

180
00:13:55,150 --> 00:14:00,220
si vous essayez de supprimer une ressource et que la ressource existe, elle sera supprimée.

181
00:14:00,220 --> 00:14:02,440
Si vous essayez de supprimer une ressource non existante,

182
00:14:02,440 --> 00:14:07,990
cela ne provoquera aucune modification supplémentaire du côté serveur Sauf

183
00:14:07,990 --> 00:14:11,808
que le serveur répondra avec une erreur indiquant que la ressource n'existe pas.

184
00:14:11,808 --> 00:14:18,700
Mais néanmoins, est un exemple d'opération dans ce cas.

185
00:14:18,700 --> 00:14:27,140
De même, l'opération get fonctionnera également car elle n'apporte aucune modification à la ressource sur le site du serveur.

186
00:14:27,140 --> 00:14:32,740
Les entrées postérieures vont bien sûr modifier la ressource côté serveur.

187
00:14:32,740 --> 00:14:34,770
Vous devez créer une nouvelle ressource ou

188
00:14:34,770 --> 00:14:40,050
modifier une ressource existante côté serveur, et bien sûr des présentations de données.

189
00:14:40,050 --> 00:14:45,050
Comme je l'ai souligné, les deux repli communs pour

190
00:14:45,050 --> 00:14:51,570
représentant est soit JSON XML, la dernière partie

191
00:14:51,570 --> 00:14:57,140
que nous devons souligner est que le côté serveur doit être complètement sans état.

192
00:14:57,140 --> 00:15:01,190
Ce qui signifie que le côté serveur ne suit pas l'état du client.

193
00:15:01,190 --> 00:15:07,060
Parce que, si le serveur doit suivre l'état du client, il ne sera pas évolutif.

194
00:15:07,060 --> 00:15:11,140
Donc, pour une implémentation évolutive du côté serveur,

195
00:15:11,140 --> 00:15:15,650
vous utilisez normalement un serveur sans état sur le côté serveur.

196
00:15:15,650 --> 00:15:19,580
Donc, si la demande des clients envoyés au serveur sera traitée comme

197
00:15:19,580 --> 00:15:25,460
une requête indépendante, et ne reflétera pas sur les requêtes

198
00:15:25,460 --> 00:15:30,790
précédentes qui ont déjà été traitées par le serveur à partir du client particulier.

199
00:15:30,790 --> 00:15:35,760
C'est donc la responsabilité du client de suivre son propre état.

200
00:15:35,760 --> 00:15:40,770
Soit sous forme d'utilisation de cookies ou d'utilisation d'une base de données de site client.

201
00:15:40,770 --> 00:15:43,780
Quel que soit le moyen qui convient.

202
00:15:43,780 --> 00:15:48,760
Maintenant, cette approche où le client suit son propre état est beaucoup plus évolutive,

203
00:15:48,760 --> 00:15:52,880
parce que votre client sera responsable du suivi des siens.

204
00:15:54,340 --> 00:15:58,880
Et c'est là que la configuration MVC côté client nous aide à cet égard.

205
00:16:00,100 --> 00:16:04,920
Et enfin, nous n'avons pas encore fini avec REST, nous verrons plus de

206
00:16:04,920 --> 00:16:10,280
REST dans les exercices qui suivent dans cette leçon particulière.

207
00:16:10,280 --> 00:16:11,563
Et puis aussi,

208
00:16:11,563 --> 00:16:17,206
, nous verrons plus de détails sur l'utilisation de REST dans le reste de ce cours.

209
00:16:17,206 --> 00:16:20,509
[MUSIQUE]