1
00:00:03,200 --> 00:00:09,035
Laissez-moi vous reposer brièvement. Je t'ai eu là.

2
00:00:09,035 --> 00:00:11,535
Ce que je voulais dire, c'est que je vous donne

3
00:00:11,535 --> 00:00:16,420
un bref aperçu du transfert d'État de représentation.

4
00:00:16,420 --> 00:00:18,460
Qu' est-ce que REST exactement ?

5
00:00:18,460 --> 00:00:22,670
Comment l'utiliser dans notre application React,

6
00:00:22,670 --> 00:00:26,130
et comment l'utiliser pour communiquer avec le serveur ?

7
00:00:26,130 --> 00:00:29,455
Comment un serveur prend-il en charge l'API REST

8
00:00:29,455 --> 00:00:34,615
et comment accéder à l'API REST à partir de notre application React ?

9
00:00:34,615 --> 00:00:39,230
Parlons un peu plus de ça dans cette leçon.

10
00:00:39,230 --> 00:00:47,680
Je suis sûr que vous avez souvent entendu parler du terme « services Web » dans le monde de l'informatique.

11
00:00:47,680 --> 00:00:49,895
Que sont exactement les services Web ?

12
00:00:49,895 --> 00:00:55,520
Les services Web sont une façon de concevoir des systèmes pour prendre en charge l'interopérabilité

13
00:00:55,520 --> 00:01:01,745
entre les systèmes connectés sur un réseau tel qu'Internet comme nous le voyons aujourd'hui.

14
00:01:01,745 --> 00:01:05,504
C' est ce que nous appelons une architecture orientée service.

15
00:01:05,504 --> 00:01:09,170
Maintenant, cela signifie que vous fournissez

16
00:01:09,170 --> 00:01:14,870
un moyen normalisé pour que deux machines connectées à Internet puissent

17
00:01:14,870 --> 00:01:17,720
communiquer entre elles au

18
00:01:17,720 --> 00:01:24,660
niveau de la couche d'application pour les applications Web utilisant des standards ouverts.

19
00:01:24,660 --> 00:01:29,175
Maintenant, j'ai utilisé beaucoup de jargon là-bas.

20
00:01:29,175 --> 00:01:32,000
Essayons de les décomposer et de comprendre

21
00:01:32,000 --> 00:01:36,195
un peu à propos de chacun de cela dans cette conférence.

22
00:01:36,195 --> 00:01:43,390
Deux approches communes utilisées pour la prise en charge des services Web sont SOAP.

23
00:01:43,390 --> 00:01:49,550
Les services Web basés sur le protocole d'accès aux objets simples qui utilisent

24
00:01:49,550 --> 00:01:52,805
le langage de description des services Web pour

25
00:01:52,805 --> 00:01:57,080
spécifier la façon dont les deux points de terminaison communiquent entre eux.

26
00:01:57,080 --> 00:02:01,700
En règle générale, SOAP est basé sur

27
00:02:01,700 --> 00:02:07,340
l'utilisation de XML comme format pour les messages échangés entre les deux points de terminaison.

28
00:02:07,340 --> 00:02:12,975
Representational State Transfer ou REST utilise également des normes Web,

29
00:02:12,975 --> 00:02:17,240
mais l'échange de données entre les deux points de terminaison pourrait être XML ou de

30
00:02:17,240 --> 00:02:22,385
plus en plus utiliser JSON comme format.

31
00:02:22,385 --> 00:02:29,705
La méthode d'interopérabilité REST est plus simple que SOAP et par conséquent,

32
00:02:29,705 --> 00:02:37,650
REST a trouvé un déploiement beaucoup plus large dans le monde des services Web.

33
00:02:37,650 --> 00:02:41,215
Généralement, la communication client-serveur est

34
00:02:41,215 --> 00:02:45,830
facilitée à l'aide de REST où le serveur prend en charge une API REST et

35
00:02:45,830 --> 00:02:49,960
le client peut alors appeler les points de terminaison de l'API REST

36
00:02:49,960 --> 00:02:54,595
afin d'obtenir des informations ou de télécharger des informations sur le serveur.

37
00:02:54,595 --> 00:02:59,885
Encore une fois, j'ai mentionné le mot invoquer les points de terminaison de l'API REST,

38
00:02:59,885 --> 00:03:03,210
donc ce sont quelques termes que j'ai utilisés.

39
00:03:03,210 --> 00:03:07,385
Clarifions certains d'entre eux dans les prochaines diapositives.

40
00:03:07,385 --> 00:03:12,590
Representational State Transfer est un style d'architecture logicielle

41
00:03:12,590 --> 00:03:18,200
spécialement conçu pour les hypermédias distribués sur le World Wide Web.

42
00:03:18,200 --> 00:03:24,604
Maintenant cela a été introduit par Roy Fielding dans sa thèse de doctorat.

43
00:03:24,604 --> 00:03:26,990
Maintenant, c'est l'une de ces thèses de doctorat

44
00:03:26,990 --> 00:03:29,660
qui a produit quelque chose d'utile pour le monde.

45
00:03:29,660 --> 00:03:38,690
Donc, cela a retrouvé beaucoup de traction dans le monde des services Web.

46
00:03:38,690 --> 00:03:42,800
Il s'agit d'un ensemble de principes réseau qui décrivent comment les

47
00:03:42,800 --> 00:03:47,300
ressources peuvent être mises à disposition sur les serveurs

48
00:03:47,300 --> 00:03:50,950
et ces ressources peuvent être accessibles à partir des clients

49
00:03:50,950 --> 00:03:56,285
en identifiant les ressources à l'aide de points de terminaison d'API de repos.

50
00:03:56,285 --> 00:03:58,855
Dans le cadre du transfert d'État de représentation,

51
00:03:58,855 --> 00:04:01,050
il existe quatre principes de base de la conception.

52
00:04:01,050 --> 00:04:05,375
Tout d'abord, REST est construit sur le protocole HTTP,

53
00:04:05,375 --> 00:04:11,365
donc il utilise toutes les méthodes HTTP que nous avons déjà vues dans la leçon précédente.

54
00:04:11,365 --> 00:04:15,045
Deuxièmement, REST est conçu pour être sans état,

55
00:04:15,045 --> 00:04:17,930
ce qui signifie que le serveur ne stocke aucune information sur

56
00:04:17,930 --> 00:04:21,450
l'état une fois la communication terminée.

57
00:04:21,450 --> 00:04:25,615
Donc, quand un serveur reçoit la requête, le serveur répond,

58
00:04:25,615 --> 00:04:29,110
puis il ne se souvient

59
00:04:29,110 --> 00:04:33,340
plus de rien de la conversation entre le client et le serveur.

60
00:04:33,340 --> 00:04:38,635
Troisièmement, la façon REST de fournir des ressources consiste à

61
00:04:38,635 --> 00:04:44,945
exposer une structure de répertoire comme des URL (Uniform Resource Locators - URL).

62
00:04:44,945 --> 00:04:50,230
Quatrièmement, le format d'échange de données est généralement JSON

63
00:04:50,230 --> 00:04:56,145
ou XML, ou les deux peuvent être pris en charge à l'aide de REST.

64
00:04:56,145 --> 00:05:03,350
Une des motivations pour Roy suggérant REST comme moyen de soutenir les services Web est

65
00:05:03,350 --> 00:05:06,620
qu'il capture toutes les choses qui sont bonnes sur

66
00:05:06,620 --> 00:05:10,880
le World Wide Web et qui ont fait du World Wide Web un succès.

67
00:05:10,880 --> 00:05:14,040
Utilisation d'indicateurs de ressources

68
00:05:14,040 --> 00:05:18,320
uniformes ou d'URL (Uniform Resource Locators) qui vous permettent d'

69
00:05:18,320 --> 00:05:23,170
adresser des ressources en les spécifiant sous forme d'URL.

70
00:05:23,170 --> 00:05:29,390
Le second, étant un protocole qui vit au-dessus du protocole HTTP.

71
00:05:29,390 --> 00:05:34,600
HTTP a déjà trouvé un large déploiement sur Internet.

72
00:05:34,600 --> 00:05:40,135
Troisièmement, le cycle de réponse de requête pour lequel HTTP est bien connu.

73
00:05:40,135 --> 00:05:42,420
Ainsi, vous envoyez une demande,

74
00:05:42,420 --> 00:05:45,775
le serveur reçoit votre demande, traite la demande,

75
00:05:45,775 --> 00:05:49,530
envoie la réponse à la demande,

76
00:05:49,530 --> 00:05:51,830
et le client reçoit la réponse,

77
00:05:51,830 --> 00:05:54,765
agit sur cela et peut générer d'autres demandes.

78
00:05:54,765 --> 00:05:58,580
Donc, cette approche du cycle de réponse à la demande est très

79
00:05:58,580 --> 00:06:03,115
bien établie avec HTTP et le World Wide Web.

80
00:06:03,115 --> 00:06:08,505
Maintenant, le protocole HTTP comme nous l'avons vu précédemment,

81
00:06:08,505 --> 00:06:13,650
nous allons utiliser tous les différents verbes que HTTP fournit.

82
00:06:13,650 --> 00:06:15,520
plus précisément, GET, PUT,

83
00:06:15,520 --> 00:06:18,635
POST et DELETE pour pouvoir

84
00:06:18,635 --> 00:06:23,480
spécifier les opérations à effectuer sur les ressources stockées côté serveur.

85
00:06:23,480 --> 00:06:27,470
Par exemple, si vous effectuez une requête HTTP GET,

86
00:06:27,470 --> 00:06:30,125
vous demandez au serveur de renvoyer la ressource.

87
00:06:30,125 --> 00:06:32,415
Si vous effectuez une requête POST,

88
00:06:32,415 --> 00:06:35,415
vous demandez au serveur de créer une nouvelle ressource.

89
00:06:35,415 --> 00:06:36,670
Si vous effectuez une requête PUT,

90
00:06:36,670 --> 00:06:39,650
vous demandez au serveur de mettre à jour une ressource existante.

91
00:06:39,650 --> 00:06:42,170
Et si vous émettez une requête DELETE,

92
00:06:42,170 --> 00:06:45,020
vous demandez au serveur de supprimer la ressource

93
00:06:45,020 --> 00:06:48,070
qui est identifiée par l'URL particulière.

94
00:06:48,070 --> 00:06:51,735
En outre, il essaie de préserver l'idempotence.

95
00:06:51,735 --> 00:06:56,165
Certaines opérations, lorsqu'elles sont effectuées même à plusieurs reprises,

96
00:06:56,165 --> 00:06:58,225
ne provoquent aucun changement d'état.

97
00:06:58,225 --> 00:07:02,085
Certaines autres opérations, si vous les faites successivement,

98
00:07:02,085 --> 00:07:05,170
elles peuvent provoquer un changement d'état.

99
00:07:05,170 --> 00:07:08,780
Vous devez donc être prudent quant aux opérations qui peuvent être répétées

100
00:07:08,780 --> 00:07:14,395
sans conséquences dommageables et qui doivent être faites avec soin.

101
00:07:14,395 --> 00:07:21,864
Dans le monde REST, vous entendez souvent des gens parler de noms, de verbes et de représentations.

102
00:07:21,864 --> 00:07:27,875
Maintenant, nous allons clarifier chacune d'entre elles un peu plus en détail dans les prochaines diapositives. Les

103
00:07:27,875 --> 00:07:31,760
noms font spécifiquement référence aux ressources et ces ressources sont

104
00:07:31,760 --> 00:07:36,320
généralement identifiées par leurs URL et celles-ci ne sont pas contraintes. Les

105
00:07:36,320 --> 00:07:40,700
verbes sont des contraintes et ceux-ci spécifient les actions à

106
00:07:40,700 --> 00:07:45,010
faire sur les ressources et les représentations comme nous le voyons.

107
00:07:45,010 --> 00:07:47,285
Lorsque les informations doivent être transmises

108
00:07:47,285 --> 00:07:49,910
du serveur au client ou du client au serveur,

109
00:07:49,910 --> 00:07:51,855
comment vous encodez les informations.

110
00:07:51,855 --> 00:07:56,520
Généralement, soit en utilisant JSON ou XML. La

111
00:07:56,520 --> 00:08:01,895
ressource est l'abstraction clé autour de laquelle REST fonctionne.

112
00:08:01,895 --> 00:08:06,810
Ainsi, l'information est abstraite sous la forme d'une ressource et la ressource

113
00:08:06,810 --> 00:08:12,475
est identifiée en la spécifiant à l'aide d'une URL.

114
00:08:12,475 --> 00:08:18,395
Ainsi, toute information qui peut être encapsulée et rendue disponible,

115
00:08:18,395 --> 00:08:20,720
peut être identifiée comme une ressource.

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

117
00:08:26,980 --> 00:08:29,345
image pourrait être une ressource, une

118
00:08:29,345 --> 00:08:33,985
information sur le cours des actions pourrait être une ressource, et ainsi de suite.

119
00:08:33,985 --> 00:08:38,920
Ainsi, tout ce que vous définissez comme un élément d'information susceptible d'intéresser un client,

120
00:08:38,920 --> 00:08:41,430
peut être identifié comme une ressource.

121
00:08:41,430 --> 00:08:44,045
Vous pouvez même traiter les ressources en tant que collection de

122
00:08:44,045 --> 00:08:48,740
ressources que le serveur peut envoyer au client.

123
00:08:48,740 --> 00:08:54,145
Un exemple de la façon dont vous nommez les ressources est illustré ici.

124
00:08:54,145 --> 00:08:57,740
Nous utilisons donc des URI pour identifier la source.

125
00:08:57,740 --> 00:09:03,355
Une lecture rapide de ces spécifications ou des URI ici

126
00:09:03,355 --> 00:09:10,460
vous permettra facilement de comprendre ce à quoi nous faisons référence en utilisant ces URI.

127
00:09:10,460 --> 00:09:14,420
Ainsi, par exemple, quelque chose qui se termine par des plates/,

128
00:09:14,420 --> 00:09:19,315
vous supposez automatiquement que cela fait référence à une collection de plats.

129
00:09:19,315 --> 00:09:22,795
Mais plats/123 par exemple,

130
00:09:22,795 --> 00:09:28,250
pourrait signifier le numéro de plat 123 dans ce cas et ainsi de suite.

131
00:09:28,250 --> 00:09:31,320
Donc, il est très facile à enregistrer et vous pouvez spécifier

132
00:09:31,320 --> 00:09:34,650
une collection de ressources et être en mesure de

133
00:09:34,650 --> 00:09:38,815
les identifier comme une collection, puis les télécharger comme une collection ou vous pouvez

134
00:09:38,815 --> 00:09:43,965
identifier une ressource individuelle et dire que vous voulez cette ressource particulière.

135
00:09:43,965 --> 00:09:50,395
Maintenant, ces ressources peuvent être organisées dans une hiérarchie de la spécification de cet URI.

136
00:09:50,395 --> 00:09:52,740
Ainsi, au fur et à mesure que

137
00:09:52,740 --> 00:09:58,325
vous traversez le chemin, vous passez du plus général au plus spécifique de la ressource.

138
00:09:58,325 --> 00:10:02,110
Cette structure de répertoires vous permet d'identifier

139
00:10:02,110 --> 00:10:07,780
très facilement les ressources que vous utilisez ou fournissez à partir de votre serveur.

140
00:10:07,780 --> 00:10:11,585
La deuxième partie de l'API REST sont les verbes.

141
00:10:11,585 --> 00:10:16,760
En particulier, nous sommes intéressés par les quatre verbes de HTTP GET,

142
00:10:16,760 --> 00:10:19,140
PUT, POST et DELETE.

143
00:10:19,140 --> 00:10:24,410
Dans ce cas, ces verbes seront mappés en actions que nous

144
00:10:24,410 --> 00:10:29,755
voulons effectuer sur la ressource, côté serveur.

145
00:10:29,755 --> 00:10:34,170
Un GET signifierait que vous souhaitez effectuer une opération de lecture sur la ressource.

146
00:10:34,170 --> 00:10:39,980
Donc, ce qui signifie qu'un client envoyant une requête GET indique au serveur qu'il

147
00:10:39,980 --> 00:10:43,480
veut obtenir une représentation

148
00:10:43,480 --> 00:10:46,380
de cette ressource du côté serveur vers le côté client.

149
00:10:46,380 --> 00:10:48,960
Un POST signifie que vous voulez créer

150
00:10:48,960 --> 00:10:52,755
une nouvelle ressource, puis vous spécifiez les détails de la ressource

151
00:10:52,755 --> 00:10:55,795
dans la représentation utilisée pour

152
00:10:55,795 --> 00:10:59,799
spécifier la ressource, puis envoyez ces informations sur le côté serveur, de

153
00:10:59,799 --> 00:11:03,285
sorte que le serveur créera cette ressource en votre nom.

154
00:11:03,285 --> 00:11:06,370
Un PUT serait une modification des ressources et

155
00:11:06,370 --> 00:11:09,955
une DELETE comme vous vous attendez est la suppression des ressources.

156
00:11:09,955 --> 00:11:12,995
Ainsi, comme vous pouvez le voir, les quatre verbes

157
00:11:12,995 --> 00:11:15,110
, GET, POST, PUT et DELETE,

158
00:11:15,110 --> 00:11:19,180
sont mappés dans les quatre opérations CRUD que vous pouvez

159
00:11:19,180 --> 00:11:24,035
effectuer sur une base de données qui stocke ces ressources côté serveur, les

160
00:11:24,035 --> 00:11:27,815
opérations READ, CREATE, UPDATE et DELETE.

161
00:11:27,815 --> 00:11:33,760
Plus en détail, le GET HTTP est un moyen de spécifier que vous

162
00:11:33,760 --> 00:11:36,950
voulez que les informations ou

163
00:11:36,950 --> 00:11:40,235
la représentation de la ressource soient renvoyées au client à partir du côté serveur.

164
00:11:40,235 --> 00:11:43,890
Ainsi, lorsque vous émettez une requête GET à un point de terminaison d'API REST,

165
00:11:43,890 --> 00:11:49,130
vous demandez soit un ensemble de ressources représentées par

166
00:11:49,130 --> 00:11:57,530
URI, soit une ressource spécifique qui est identifiée par l'ID de cette ressource particulière,

167
00:11:57,530 --> 00:11:59,490
spécifié dans l'URL.

168
00:11:59,490 --> 00:12:01,000
Donc, comme vous le voyez dans cet exemple,

169
00:12:01,000 --> 00:12:03,800
si vous dites, plates/452,

170
00:12:03,800 --> 00:12:08,320
vous voulez dire que le plat numéro 452 avec

171
00:12:08,320 --> 00:12:13,075
l'ID 452 doit être retourné côté client.

172
00:12:13,075 --> 00:12:18,175
De même, l'opération POST comme nous l'avons vu est utilisée pour créer la ressource.

173
00:12:18,175 --> 00:12:20,065
Ainsi, lorsque vous créez la ressource,

174
00:12:20,065 --> 00:12:26,920
le contenu de la description de la ressource se présente sous la forme d'une représentation JSON ou

175
00:12:26,920 --> 00:12:29,790
d'une représentation XML et sera inclus dans

176
00:12:29,790 --> 00:12:34,075
le corps du message de requête qui est envoyé au côté serveur.

177
00:12:34,075 --> 00:12:38,095
Ainsi, une opération POST attend une représentation de

178
00:12:38,095 --> 00:12:42,870
la ressource au format JSON ou XML dans le corps du message de requête.

179
00:12:42,870 --> 00:12:44,890
Lorsque le serveur reçoit ce message de demande,

180
00:12:44,890 --> 00:12:49,960
le serveur crée cette ressource côté serveur, puis renvoie

181
00:12:49,960 --> 00:12:58,030
une conformation ou une erreur pour indiquer que la création de la ressource a échoué.

182
00:12:58,030 --> 00:13:02,725
De même, une opération PUT est utilisée pour mettre à jour une ressource.

183
00:13:02,725 --> 00:13:06,315
Lorsque vous effectuez une opération PUT sur une ressource côté serveur,

184
00:13:06,315 --> 00:13:10,200
vous pouvez renvoyer la modification

185
00:13:10,200 --> 00:13:15,470
soit en spécifiant uniquement la modification partielle que vous souhaitez affecter à

186
00:13:15,470 --> 00:13:20,200
la ressource particulière dans le corps du message de réponse, soit vous pouvez envoyer

187
00:13:20,200 --> 00:13:25,345
la représentation complète de la dans le corps du message.

188
00:13:25,345 --> 00:13:28,705
Selon l'arrangement entre le client et le serveur,

189
00:13:28,705 --> 00:13:37,195
le serveur s'attend à ce que les informations soient transmises dans le corps du message de requête.

190
00:13:37,195 --> 00:13:42,600
Une opération DELETE comme vous vous attendez supprime la ressource existante.

191
00:13:42,600 --> 00:13:45,460
Maintenant, dans ce cas particulier,

192
00:13:45,460 --> 00:13:49,670
bien sûr, une opération DELETE serait idempotente car si vous

193
00:13:49,670 --> 00:13:54,145
essayez de supprimer une ressource et que la ressource existe, elle sera supprimée.

194
00:13:54,145 --> 00:13:56,445
Si vous essayez de supprimer une ressource non existante,

195
00:13:56,445 --> 00:14:01,220
cela ne provoquera aucune modification supplémentaire sur le côté serveur,

196
00:14:01,220 --> 00:14:06,165
sauf que le serveur répondra avec une erreur indiquant que la ressource n'existe pas.

197
00:14:06,165 --> 00:14:12,530
Mais, néanmoins, DELETE est un exemple d'opération idempotente dans ce cas.

198
00:14:12,530 --> 00:14:16,510
De même, l'opération GET est également une opération idempotente car elle

199
00:14:16,510 --> 00:14:20,885
n'apporte aucune modification à la ressource côté serveur.

200
00:14:20,885 --> 00:14:26,925
POST et PUT vont bien sûr modifier la ressource côté serveur,

201
00:14:26,925 --> 00:14:31,940
soit créer une nouvelle ressource ou modifier une ressource existante côté serveur.

202
00:14:31,940 --> 00:14:34,060
Bien sûr, les représentations,

203
00:14:34,060 --> 00:14:36,730
comme je l'ai souligné,

204
00:14:36,730 --> 00:14:43,980
les deux formats communs de représentation sont soit JSON soit XML.

205
00:14:43,980 --> 00:14:47,105
La dernière partie que nous devons souligner est

206
00:14:47,105 --> 00:14:51,060
que le côté serveur doit être complètement sans état,

207
00:14:51,060 --> 00:14:53,640
ce qui signifie que le côté serveur ne suit pas l'

208
00:14:53,640 --> 00:14:59,145
état du client car si le serveur a besoin de suivre l'état des clients,

209
00:14:59,145 --> 00:15:00,935
il ne sera pas évolutif.

210
00:15:00,935 --> 00:15:05,160
Ainsi, pour une implémentation évolutive du côté serveur,

211
00:15:05,160 --> 00:15:09,620
vous utilisez normalement un serveur sans état côté serveur.

212
00:15:09,620 --> 00:15:12,910
Ainsi, chaque requête que le client envoie au serveur sera

213
00:15:12,910 --> 00:15:16,490
traitée comme une requête indépendante et

214
00:15:16,490 --> 00:15:20,330
ne reflètera pas les requêtes précédentes

215
00:15:20,330 --> 00:15:24,685
qui ont déjà été traitées par le serveur à partir de ce client particulier.

216
00:15:24,685 --> 00:15:29,605
Donc, il est de la responsabilité du client de suivre son propre état,

217
00:15:29,605 --> 00:15:34,635
soit sous la forme d'utiliser des cookies ou d'utiliser une base de données côté client,

218
00:15:34,635 --> 00:15:37,435
quel que soit le moyen approprié.

219
00:15:37,435 --> 00:15:41,790
Maintenant, cette approche où le client suit son propre état est

220
00:15:41,790 --> 00:15:44,815
beaucoup plus évolutive car chaque client individuel

221
00:15:44,815 --> 00:15:48,240
sera responsable du suivi de son propre état.

222
00:15:48,240 --> 00:15:53,840
C' est là que la configuration MVC côté client nous aide à cet égard.

223
00:15:53,840 --> 00:15:57,440
Enfin, nous n'avons pas encore fini avec REST.

224
00:15:57,440 --> 00:16:04,145
Nous verrons plus de REST dans les exercices qui suivent dans cette leçon particulière

225
00:16:04,145 --> 00:16:12,310
, puis nous verrons aussi plus de détails sur l'utilisation de REST dans le reste de ce cours.