1
00:00:01,670 --> 00:00:04,320
‫Instructeur : Maintenant que nous savons ce qu'est

2
00:00:04,320 --> 00:00:07,550
‫Express, nous sommes presque prêts à commencer à créer notre API.

3
00:00:07,550 --> 00:00:08,890
‫Mais avant de

4
00:00:08,890 --> 00:00:12,300
‫faire cela, je dois parler rapidement des API à

5
00:00:12,300 --> 00:00:13,910
‫un niveau supérieur et,

6
00:00:13,910 --> 00:00:16,370
‫plus important encore, vous présenter l'architecture

7
00:00:16,370 --> 00:00:19,640
‫REST, qui est l'architecture d'API la plus utilisée aujourd'hui.

8
00:00:19,640 --> 00:00:23,270
‫De cette façon, nous saurons réellement ce que nous construisons.

9
00:00:23,270 --> 00:00:25,710
‫Il est donc extrêmement important de comprendre le

10
00:00:25,710 --> 00:00:27,860
‫contenu de cette vidéo avant de poursuivre,

11
00:00:27,860 --> 00:00:30,580
‫afin que nous sachions réellement ce que nous construisons

12
00:00:30,580 --> 00:00:32,603
‫tout au long du cours.

13
00:00:33,630 --> 00:00:34,890
‫Tout d'abord,

14
00:00:34,890 --> 00:00:38,390
‫API signifie Application Programming Interface et à un niveau

15
00:00:38,390 --> 00:00:40,130
‫très élevé, il s'agit

16
00:00:40,130 --> 00:00:43,150
‫essentiellement d'un logiciel qui peut être utilisé par

17
00:00:43,150 --> 00:00:45,270
‫un autre logiciel afin de

18
00:00:45,270 --> 00:00:48,213
‫permettre aux applications de communiquer entre elles.

19
00:00:49,080 --> 00:00:51,420
‫Nous avons en fait déjà parlé

20
00:00:51,420 --> 00:00:53,780
‫des API, plus précisément des API Web,

21
00:00:53,780 --> 00:00:56,300
‫où nous avons simplement créé une application qui

22
00:00:56,300 --> 00:00:59,640
‫envoie des données à un client chaque fois qu'une demande arrive.

23
00:00:59,640 --> 00:01:02,530
‫Imaginez que notre application fonctionne sur un serveur et que

24
00:01:02,530 --> 00:01:04,060
‫nous ayons un client.

25
00:01:04,060 --> 00:01:08,020
‫Donc, en fait, nous avons effectivement deux logiciels qui

26
00:01:08,020 --> 00:01:10,250
‫se parlent, n'est-ce pas ?

27
00:01:10,250 --> 00:01:13,550
‫Et c'est le genre d'API que nous allons construire dans ce cours.

28
00:01:13,550 --> 00:01:17,470
‫Et je suppose que c'est le type d'API le plus largement utilisé.

29
00:01:17,470 --> 00:01:21,970
‫Mais en fait, les API ne sont pas seulement utilisées pour envoyer des données et

30
00:01:21,970 --> 00:01:25,493
‫ne sont pas toujours liées au développement Web ou à JavaScript.

31
00:01:26,400 --> 00:01:29,500
‫L'application dans l'API peut en fait signifier

32
00:01:29,500 --> 00:01:32,710
‫beaucoup de choses différentes tant que le

33
00:01:32,710 --> 00:01:35,050
‫logiciel est relativement autonome.

34
00:01:35,050 --> 00:01:35,900
‫Prenez, par

35
00:01:35,900 --> 00:01:38,870
‫exemple, le système de fichiers de nœuds ou les modules HTTP.

36
00:01:38,870 --> 00:01:42,010
‫Nous pouvons dire que ce sont de petits logiciels

37
00:01:42,010 --> 00:01:43,110
‫et nous pouvons

38
00:01:43,110 --> 00:01:46,970
‫les utiliser, nous pouvons interagir avec eux en utilisant leur API.

39
00:01:46,970 --> 00:01:47,803
‫Par

40
00:01:47,803 --> 00:01:51,150
‫exemple, lorsque nous utilisons la fonction readfile du module

41
00:01:51,150 --> 00:01:54,020
‫FS, nous utilisons en fait l'API FS.

42
00:01:54,020 --> 00:01:57,380
‫Et c'est pourquoi vous entendrez parfois le terme d'API de nœuds.

43
00:01:57,380 --> 00:02:01,090
‫Et cela fait généralement simplement référence aux modules de nœud de base

44
00:02:01,090 --> 00:02:02,920
‫avec lesquels nous pouvons interagir.

45
00:02:02,920 --> 00:02:05,670
‫Ou lorsque nous faisons de la manipulation DOM

46
00:02:05,670 --> 00:02:08,650
‫dans le navigateur, nous n'utilisons pas vraiment le langage

47
00:02:08,650 --> 00:02:12,440
‫JavaScript lui-même, mais plutôt l'API DOM que le navigateur nous expose, donc

48
00:02:12,440 --> 00:02:14,280
‫il nous y donne accès.

49
00:02:14,280 --> 00:02:15,930
‫Ou même un autre exemple,

50
00:02:15,930 --> 00:02:19,080
‫disons que nous créons une classe dans n'importe quel langage

51
00:02:19,080 --> 00:02:21,940
‫de programmation comme Java, puis y ajoutons des méthodes

52
00:02:21,940 --> 00:02:23,420
‫ou des propriétés publiques.

53
00:02:23,420 --> 00:02:26,860
‫Ces méthodes seront alors l'API de chaque objet

54
00:02:26,860 --> 00:02:29,450
‫créé à partir de cette classe

55
00:02:29,450 --> 00:02:31,890
‫car nous donnons à d'autres logiciels

56
00:02:31,890 --> 00:02:35,420
‫la possibilité d'interagir avec notre logiciel initial, les objets,

57
00:02:35,420 --> 00:02:37,278
‫dans ce cas.

58
00:02:37,278 --> 00:02:40,810
‫Vous voyez, l'API a en fait un sens plus large que

59
00:02:40,810 --> 00:02:42,810
‫la simple création d'API Web.

60
00:02:42,810 --> 00:02:47,420
‫Bien? Quoi qu'il en soit, une API Web est ce

61
00:02:47,420 --> 00:02:50,340
‫qui est le plus important pour nous dans le contexte de la note.

62
00:02:50,340 --> 00:02:53,050
‫Jetons maintenant un coup d'œil à l'architecture REST pour

63
00:02:53,050 --> 00:02:54,203
‫créer des API.

64
00:02:55,820 --> 00:02:59,910
‫REST, qui signifie Representational States Transfer, est essentiellement un moyen de

65
00:02:59,910 --> 00:03:03,930
‫créer des API Web de manière logique, ce qui les

66
00:03:03,930 --> 00:03:06,060
‫rend faciles à utiliser,

67
00:03:06,060 --> 00:03:09,420
‫car rappelez-vous, nous créons une API pour nous-mêmes

68
00:03:09,420 --> 00:03:12,023
‫ou pour d'autres à consommer, d'accord ?

69
00:03:12,023 --> 00:03:15,640
‫Nous voulons rendre le processus d'utilisation de l'API aussi fluide

70
00:03:15,640 --> 00:03:17,633
‫que possible pour l'utilisateur.

71
00:03:18,490 --> 00:03:20,830
‫Maintenant, pour créer des API

72
00:03:20,830 --> 00:03:24,180
‫RESTful, c'est-à-dire des API suivant l'architecture REST, il

73
00:03:24,180 --> 00:03:26,660
‫nous suffit de suivre quelques principes.

74
00:03:26,660 --> 00:03:31,240
‫Tout d'abord, nous devons séparer notre API en ressources logiques.

75
00:03:31,240 --> 00:03:33,860
‫Ces ressources doivent ensuite être exposées, ce

76
00:03:33,860 --> 00:03:35,900
‫qui signifie être rendues

77
00:03:35,900 --> 00:03:39,420
‫disponibles à l'aide d'URL structurées et basées sur les ressources.

78
00:03:39,420 --> 00:03:41,460
‫Pour effectuer différentes actions sur

79
00:03:41,460 --> 00:03:44,677
‫des données telles que la lecture ou la création

80
00:03:44,677 --> 00:03:49,677
‫ou la suppression de données, l'API doit utiliser les bonnes méthodes HTP et non l'URL.

81
00:03:50,270 --> 00:03:53,210
‫Désormais, les données que nous renvoyons réellement au

82
00:03:53,210 --> 00:03:55,420
‫client ou que nous avons

83
00:03:55,420 --> 00:03:58,030
‫reçues du client doivent généralement utiliser le format

84
00:03:58,030 --> 00:04:01,010
‫de données JSON, auquel une norme de formatage s'applique.

85
00:04:01,010 --> 00:04:04,500
‫Enfin, un autre principe important des API REST

86
00:04:04,500 --> 00:04:07,560
‫est qu'elles doivent être sans état.

87
00:04:07,560 --> 00:04:09,950
‫C'est donc une vue d'ensemble très large.

88
00:04:09,950 --> 00:04:12,030
‫Commençons maintenant à parler de ces principes

89
00:04:12,030 --> 00:04:15,310
‫un par un en commençant par les ressources et en utilisant

90
00:04:15,310 --> 00:04:17,810
‫l'API Nators que nous allons construire dans ce

91
00:04:17,810 --> 00:04:19,803
‫cours à titre d'exemple ici.

92
00:04:20,960 --> 00:04:24,910
‫L'abstraction clé des informations dans REST est une ressource, et

93
00:04:24,910 --> 00:04:27,450
‫donc toutes les données que

94
00:04:27,450 --> 00:04:32,040
‫nous voulons partager dans l'API doivent être divisées en ressources logiques.

95
00:04:32,040 --> 00:04:34,350
‫Maintenant, qu'est-ce qu'une ressource ?

96
00:04:34,350 --> 00:04:36,380
‫Eh bien, dans le contexte

97
00:04:36,380 --> 00:04:39,520
‫de REST, c'est un objet ou une représentation de

98
00:04:39,520 --> 00:04:42,020
‫quelque chose auquel des données sont associées.

99
00:04:42,020 --> 00:04:42,853
‫Par exemple,

100
00:04:42,853 --> 00:04:45,570
‫des visites, ou des utilisateurs, ou des avis dans

101
00:04:45,570 --> 00:04:48,020
‫le cas de l'exemple que nous suivons.

102
00:04:48,020 --> 00:04:50,730
‫Donc, fondamentalement, toute information pouvant être nommée peut

103
00:04:50,730 --> 00:04:53,040
‫être une ressource, d'accord ?

104
00:04:53,040 --> 00:04:56,050
‫Il doit juste être un nom, cependant, pas un verbe.

105
00:04:56,050 --> 00:04:57,690
‫Maintenant, nous devons

106
00:04:57,690 --> 00:04:59,480
‫exposer, c'est-à-dire rendre disponibles,

107
00:04:59,480 --> 00:05:02,520
‫les données en utilisant des URL structurées auxquelles

108
00:05:02,520 --> 00:05:04,890
‫le client peut envoyer une requête.

109
00:05:04,890 --> 00:05:07,611
‫Par exemple, quelque chose comme ça.

110
00:05:07,611 --> 00:05:10,740
‫Cette adresse entière est appelée l'URL et

111
00:05:10,740 --> 00:05:14,323
‫ce /addNewTour est appelé un point de terminaison d'API.

112
00:05:15,269 --> 00:05:17,840
‫Notre API aura de nombreux points de terminaison

113
00:05:17,840 --> 00:05:20,560
‫différents, tout comme ces points de terminaison fictifs

114
00:05:20,560 --> 00:05:23,730
‫que j'ai ici, dont chacun renverra des données différentes au

115
00:05:23,730 --> 00:05:26,150
‫client ou effectuera également différentes actions.

116
00:05:26,150 --> 00:05:28,440
‫Maintenant, il y a en fait quelque

117
00:05:28,440 --> 00:05:31,750
‫chose qui ne va pas avec ces points de terminaison ici, car

118
00:05:31,750 --> 00:05:34,827
‫ils ne suivent vraiment pas la troisième règle qui dit que

119
00:05:34,827 --> 00:05:39,110
‫nous ne devons utiliser les méthodes HTTP que pour effectuer des actions sur les données.

120
00:05:39,110 --> 00:05:42,360
‫Ainsi, les endpoints ne doivent contenir que nos ressources et

121
00:05:42,360 --> 00:05:45,070
‫non les actions qui peuvent être effectuées

122
00:05:45,070 --> 00:05:48,313
‫sur eux car ils deviendront rapidement un cauchemar à maintenir.

123
00:05:49,644 --> 00:05:54,210
‫Comment devrions-nous utiliser ces méthodes HTTP en pratique ?

124
00:05:54,210 --> 00:05:56,120
‫Eh bien, voyons à quoi

125
00:05:56,120 --> 00:05:59,620
‫devraient ressembler ces points de terminaison en commençant par /getTour.

126
00:05:59,620 --> 00:06:03,290
‫Donc, ce point de terminaison /getTour sert à obtenir des données sur une visite.

127
00:06:03,290 --> 00:06:06,240
‫Et donc nous devons simplement nommer le point de terminaison /tours et

128
00:06:06,240 --> 00:06:08,740
‫envoyer les données chaque fois qu'une demande d'obtention est

129
00:06:08,740 --> 00:06:10,430
‫faite à ce point de terminaison.

130
00:06:10,430 --> 00:06:11,650
‫Donc, en d'autres

131
00:06:11,650 --> 00:06:14,730
‫termes, lorsqu'un client utilise une méthode GET HTTP pour

132
00:06:14,730 --> 00:06:16,700
‫accéder au point de terminaison.

133
00:06:16,700 --> 00:06:17,870
‫Et juste comme

134
00:06:17,870 --> 00:06:20,220
‫ça, nous n'avons que des ressources dans le

135
00:06:20,220 --> 00:06:23,670
‫point de terminaison ou dans l'URL et pas de verbes car le

136
00:06:23,670 --> 00:06:26,870
‫verbe est maintenant dans la méthode HTTP, n'est-ce pas ?

137
00:06:26,870 --> 00:06:27,703
‫Et au

138
00:06:27,703 --> 00:06:30,490
‫fait, c'est une pratique courante de toujours utiliser le

139
00:06:30,490 --> 00:06:34,820
‫nom de la ressource au pluriel, c'est pourquoi j'ai /tours ici et non /tour.

140
00:06:34,820 --> 00:06:37,790
‫Maintenant, la convention est que lors de l'appel de ce point

141
00:06:37,790 --> 00:06:41,820
‫de terminaison, nous récupérons toutes les visites qui se trouvent dans une base de données, d'accord ?

142
00:06:41,820 --> 00:06:44,820
‫Mais si nous voulons seulement la tournée avec un seul I. RÉ. disons sept, nous ajoutons

143
00:06:44,820 --> 00:06:48,960
‫que sept après une autre barre oblique ou dans une requête de recherche.

144
00:06:48,960 --> 00:06:50,580
‫Ou cela pourrait aussi être le nom d'une tournée au lieu du I. RÉ. ou un autre identifiant unique.

145
00:06:50,580 --> 00:06:53,490
‫Les détails n'ont pas vraiment d'importance à ce stade, d'accord ?

146
00:06:53,490 --> 00:06:55,410
‫Plus tard, je vous montrerai à

147
00:06:55,410 --> 00:06:58,300
‫quel point il est facile d'implémenter ce type de logique

148
00:06:58,300 --> 00:07:01,180
‫avec Express, car c'est en fait là qu'Express brille vraiment.

149
00:07:01,180 --> 00:07:03,410
‫La première méthode ou verbe

150
00:07:03,410 --> 00:07:06,733
‫HTTP auquel nous pouvons répondre est GET et est utilisé

151
00:07:07,606 --> 00:07:10,460
‫pour effectuer l'opération de lecture sur les données.

152
00:07:10,460 --> 00:07:12,530
‫Prochain arrêt, si le client

153
00:07:12,530 --> 00:07:16,290
‫souhaite créer une nouvelle ressource dans notre base de données,

154
00:07:16,290 --> 00:07:18,290
‫dans cet exemple, une

155
00:07:18,290 --> 00:07:21,450
‫nouvelle tournée, la méthode POST doit être utilisée.

156
00:07:21,450 --> 00:07:23,200
‫Nous avons donc appris plus tôt qu'une

157
00:07:23,200 --> 00:07:25,510
‫requête POST peut être utilisée pour envoyer des données

158
00:07:25,510 --> 00:07:28,490
‫au serveur, et il est donc logique d'utiliser POST afin de créer

159
00:07:28,490 --> 00:07:30,230
‫de nouvelles ressources, n'est-ce pas ?

160
00:07:30,230 --> 00:07:32,270
‫Maintenant, dans ce cas, généralement pas de I. RÉ. sera envoyé car

161
00:07:32,270 --> 00:07:35,530
‫le serveur devrait automatiquement trouver le

162
00:07:35,530 --> 00:07:38,530
‫I. RÉ. pour la nouvelle ressource.

163
00:07:38,530 --> 00:07:40,860
‫Quoi qu'il en soit, ce qui est vraiment important à noter ici, c'est que le nom du point de terminaison est

164
00:07:40,860 --> 00:07:42,948
‫exactement le même nom qu'avant.

165
00:07:42,948 --> 00:07:46,090
‫La seule différence est vraiment

166
00:07:46,090 --> 00:07:50,289
‫la méthode HTP utilisée pour la requête.

167
00:07:50,289 --> 00:07:53,870
‫Si le point de terminaison /tours est accessible avec GET, nous

168
00:07:53,870 --> 00:07:55,960
‫envoyons des données au client.

169
00:07:55,960 --> 00:07:59,410
‫Mais si le même point de terminaison est accessible avec POST, nous

170
00:07:59,410 --> 00:08:01,460
‫nous attendons à ce que

171
00:08:01,460 --> 00:08:04,060
‫les données arrivent avec une demande, afin que nous

172
00:08:04,060 --> 00:08:06,550
‫puissions ensuite créer une nouvelle ressource côté serveur.

173
00:08:06,550 --> 00:08:08,760
‫C'est donc vraiment la beauté de n'utiliser que des méthodes HTTP plutôt que de jouer

174
00:08:08,760 --> 00:08:10,330
‫avec les verbes dans les noms de points de terminaison.

175
00:08:10,330 --> 00:08:14,460
‫Encore une fois, cela deviendrait vraiment ingérable très rapidement.

176
00:08:14,460 --> 00:08:17,480
‫D'accord, ensuite, il devrait également y

177
00:08:17,480 --> 00:08:21,210
‫avoir la possibilité de mettre à jour les ressources.

178
00:08:21,210 --> 00:08:23,620
‫Et pour cela, une demande PUT

179
00:08:23,620 --> 00:08:26,390
‫ou PATCH doit être faite au point

180
00:08:26,390 --> 00:08:27,310
‫de terminaison.

181
00:08:27,310 --> 00:08:29,550
‫La différence entre eux est qu'avec PUT,

182
00:08:29,550 --> 00:08:31,550
‫le client est censé envoyer l'intégralité

183
00:08:31,550 --> 00:08:33,750
‫de l'objet mis à jour, tandis qu'avec

184
00:08:33,750 --> 00:08:37,280
‫PATCH, il est censé envoyer uniquement la partie de l'objet qui

185
00:08:37,280 --> 00:08:38,370
‫a été modifiée.

186
00:08:38,370 --> 00:08:40,967
‫Mais les deux ont la possibilité d'envoyer

187
00:08:40,967 --> 00:08:43,060
‫des données au serveur.

188
00:08:43,060 --> 00:08:45,140
‫Un peu comme POST, en fait, mais avec une intention différente.

189
00:08:45,140 --> 00:08:46,750
‫Donc POST consiste à

190
00:08:46,750 --> 00:08:50,750
‫créer une nouvelle ressource, tandis que PUT ou PATCH sont utilisés pour

191
00:08:50,750 --> 00:08:53,070
‫mettre à jour une ressource existante et

192
00:08:53,070 --> 00:08:55,370
‫donc cela fait alors toute la différence.

193
00:08:55,370 --> 00:08:57,500
‫Et enfin, à la ressource litière,

194
00:08:57,500 --> 00:08:59,660
‫il y a la méthode HTTP DELETE.

195
00:08:59,660 --> 00:09:02,110
‫Encore une fois, le I. RÉ. ou un autre identifiant unique de

196
00:09:02,110 --> 00:09:05,110
‫la ressource à supprimer doit faire partie de

197
00:09:05,110 --> 00:09:08,010
‫l'URL.

198
00:09:08,010 --> 00:09:10,120
‫Or, généralement, pour pouvoir réellement

199
00:09:10,120 --> 00:09:11,820
‫effectuer ce type

200
00:09:11,820 --> 00:09:14,560
‫de requête, le client doit être authentifié.

201
00:09:14,560 --> 00:09:16,610
‫Donc en gros, connectez-vous à votre application, d'accord ?

202
00:09:16,610 --> 00:09:18,620
‫Mais c'est, bien sûr, un sujet pour beaucoup plus tard.

203
00:09:18,620 --> 00:09:21,670
‫Ce sont donc les cinq méthodes HTTP auxquelles

204
00:09:21,670 --> 00:09:24,349
‫nous pouvons et devons répondre lors de

205
00:09:24,349 --> 00:09:27,080
‫la création de nos API RESTful afin

206
00:09:27,080 --> 00:09:29,320
‫que le client puisse effectuer

207
00:09:29,320 --> 00:09:31,570
‫les quatre opérations CRUD de base.

208
00:09:31,570 --> 00:09:33,270
‫CRUD signifie donc créer, lire, mettre à jour et supprimer.

209
00:09:33,270 --> 00:09:36,290
‫Et vous verrez ce terme tout

210
00:09:36,290 --> 00:09:40,730
‫le temps lié aux API et aux bases de données.

211
00:09:40,730 --> 00:09:42,590
‫Et vous voyez que ces méthodes

212
00:09:42,590 --> 00:09:45,200
‫HTTP correspondent assez bien aux opérations CRUD de base.

213
00:09:45,200 --> 00:09:47,490
‫Maintenant, il peut y avoir des

214
00:09:47,490 --> 00:09:51,330
‫actions qui ne sont pas CRUD, et dans ce cas, nous

215
00:09:51,330 --> 00:09:54,410
‫devons juste faire preuve de créativité avec nos entrées.

216
00:09:54,410 --> 00:09:55,460
‫Par exemple, une connexion

217
00:09:55,460 --> 00:09:58,120
‫ou une opération de recherche, celles-ci ne sont pas vraiment liées

218
00:09:58,120 --> 00:09:58,953
‫à une ressource

219
00:09:58,953 --> 00:10:01,010
‫particulière et ce ne sont pas non plus

220
00:10:01,010 --> 00:10:04,361
‫des opérations CRUD, mais nous pouvons toujours créer des points de terminaison pour elles.

221
00:10:04,361 --> 00:10:06,630
‫Par exemple, comme /login ou /search.

222
00:10:06,630 --> 00:10:09,240
‫Mais nous parlerons davantage de ces cas plus tard dans la pratique.

223
00:10:09,240 --> 00:10:12,530
‫Et juste pour terminer cette partie maintenant, rappelez-vous que nous

224
00:10:12,530 --> 00:10:16,350
‫avions deux autres noms de points de terminaison fous dans la dernière

225
00:10:16,350 --> 00:10:18,290
‫diapositive qui impliquaient en quelque

226
00:10:18,290 --> 00:10:21,330
‫sorte deux ressources en même temps, n'est-ce pas ?

227
00:10:21,330 --> 00:10:23,870
‫Et ce n'est pas non plus un problème avec REST.

228
00:10:23,870 --> 00:10:26,780
‫Ainsi, /getToursByUser peut

229
00:10:26,780 --> 00:10:29,888
‫simplement être traduit en /users/tours,

230
00:10:29,888 --> 00:10:33,810
‫dans ce cas, l'utilisateur numéro trois.

231
00:10:33,810 --> 00:10:36,210
‫Ainsi, ce point de terminaison particulier ici pourrait

232
00:10:36,210 --> 00:10:38,440
‫envoyer des données sur toutes les visites que

233
00:10:38,440 --> 00:10:40,200
‫l'utilisateur numéro trois a réservées.

234
00:10:40,200 --> 00:10:42,340
‫Logique?

235
00:10:42,340 --> 00:10:44,580
‫Ou dans le cas d'une suppression, il pourrait y avoir

236
00:10:44,580 --> 00:10:45,519
‫une demande de

237
00:10:45,519 --> 00:10:47,470
‫suppression au même point de terminaison ou à un

238
00:10:47,470 --> 00:10:50,170
‫point de terminaison très similaire, demandant à la tournée numéro neuf d'être

239
00:10:50,170 --> 00:10:51,910
‫supprimée de l'utilisateur numéro trois, d'accord ?

240
00:10:51,910 --> 00:10:54,440
‫Il y a donc vraiment des tonnes

241
00:10:54,440 --> 00:10:57,330
‫de possibilités de combiner des ressources comme celle-ci.

242
00:10:57,330 --> 00:11:00,160
‫Mais bien sûr, nous n'avons pas à implémenter

243
00:11:00,160 --> 00:11:02,470
‫toutes ces combinaisons dans notre API.

244
00:11:02,470 --> 00:11:04,260
‫Nous implémentons uniquement ce qui a

245
00:11:04,260 --> 00:11:06,600
‫du sens dans le cas de notre application et

246
00:11:06,600 --> 00:11:08,400
‫du client qui souhaite consommer notre API.

247
00:11:08,400 --> 00:11:10,090
‫C'est ainsi que nous

248
00:11:10,090 --> 00:11:13,203
‫utilisons les méthodes HTTP pour créer des URL

249
00:11:13,203 --> 00:11:17,480
‫conviviales et bien structurées, faciles et logiques à utiliser pour le client.

250
00:11:17,480 --> 00:11:20,823
‫Maintenant, à propos des données que le client reçoit

251
00:11:20,823 --> 00:11:24,145
‫réellement ou que le serveur reçoit du

252
00:11:24,145 --> 00:11:27,800
‫client, nous utilisons généralement le format de données JSON.

253
00:11:27,800 --> 00:11:30,610
‫Et apprenons donc brièvement ce qu'est réellement JSON

254
00:11:30,610 --> 00:11:33,203
‫et comment formater nos réponses API.

255
00:11:34,440 --> 00:11:37,400
‫JSON est un format d'échange de données très

256
00:11:37,400 --> 00:11:39,530
‫léger qui est largement utilisé

257
00:11:39,530 --> 00:11:43,780
‫par les API Web codées dans n'importe quel langage de programmation.

258
00:11:43,780 --> 00:11:46,220
‫Donc, ce n'est tout simplement pas lié à un JavaScript.

259
00:11:46,220 --> 00:11:48,160
‫Et il est si largement utilisé aujourd'hui

260
00:11:48,160 --> 00:11:50,740
‫parce qu'il est vraiment facile pour les humains et les

261
00:11:50,740 --> 00:11:52,620
‫ordinateurs de comprendre et d'écrire JSON.

262
00:11:52,620 --> 00:11:55,930
‫Vous avez donc probablement déjà remarqué que JSON ressemble un peu à

263
00:11:55,930 --> 00:11:57,990
‫un objet JavaScript normal, n'est-ce pas ?

264
00:11:57,990 --> 00:12:00,510
‫Avec toutes ces paires clé-valeur.

265
00:12:00,510 --> 00:12:04,020
‫Il existe cependant quelques différences, et la plus importante

266
00:12:04,020 --> 00:12:06,470
‫est que toutes les clés doivent

267
00:12:06,470 --> 00:12:08,320
‫être des chaînes.

268
00:12:08,320 --> 00:12:10,960
‫Il est également très courant que les valeurs soient également des

269
00:12:10,960 --> 00:12:12,580
‫chaînes, mais il peut s'agir d'autres

270
00:12:12,580 --> 00:12:14,730
‫éléments tels que des nombres, des valeurs vraies

271
00:12:14,730 --> 00:12:17,440
‫ou fausses, un autre objet ou même des tableaux d'autres valeurs.

272
00:12:17,440 --> 00:12:20,690
‫C'est assez simple, en fait.

273
00:12:20,690 --> 00:12:23,328
‫Et à partir de cet exemple, vous pouvez en quelque

274
00:12:23,328 --> 00:12:25,790
‫sorte voir à quoi pourrait ressembler un JSON typique.

275
00:12:25,790 --> 00:12:27,070
‫Disons qu'il s'agit

276
00:12:27,070 --> 00:12:30,883
‫d'une donnée que nous avons dans notre base de données pour une

277
00:12:31,890 --> 00:12:35,290
‫requête GET vers cette URL donc la tournée avec I. RÉ. des cinq.

278
00:12:35,290 --> 00:12:38,560
‫Maintenant, nous pourrions le renvoyer comme ceci au client, mais

279
00:12:38,560 --> 00:12:41,440
‫nous effectuons

280
00:12:41,440 --> 00:12:44,300
‫généralement un formatage de réponse simple avant de l'envoyer.

281
00:12:44,300 --> 00:12:47,130
‫Il existe quelques normes pour cela et nous allons en utiliser

282
00:12:47,130 --> 00:12:48,620
‫une très simple appelée Jsend.

283
00:12:48,620 --> 00:12:50,880
‫Nous créons simplement un nouvel objet, puis

284
00:12:50,880 --> 00:12:54,570
‫y ajoutons un message d'état afin d'informer le client si la

285
00:12:54,570 --> 00:12:56,320
‫demande a été un

286
00:12:56,320 --> 00:12:58,310
‫succès, un échec ou une

287
00:12:58,310 --> 00:13:00,740
‫erreur, puis nous mettons nos données d'origine

288
00:13:00,740 --> 00:13:03,350
‫dans un nouvel objet appelé Data, d'accord ?

289
00:13:03,350 --> 00:13:05,390
‫Et nous pouvons développer cela

290
00:13:05,390 --> 00:13:08,510
‫encore un peu plus loin, mais c'est vraiment le moyen

291
00:13:08,510 --> 00:13:10,640
‫le plus simple de formater avec Jsend.

292
00:13:10,640 --> 00:13:12,020
‫Et, soit dit en passant,

293
00:13:12,020 --> 00:13:14,250
‫envelopper les données dans un objet supplémentaire comme

294
00:13:14,250 --> 00:13:15,240
‫nous l'avons

295
00:13:15,240 --> 00:13:17,550
‫fait ici s'appelle Envelopper, et c'est une pratique courante

296
00:13:17,550 --> 00:13:19,860
‫pour atténuer certains problèmes de sécurité et d'autres problèmes.

297
00:13:19,860 --> 00:13:21,470
‫En outre, il existe

298
00:13:21,470 --> 00:13:25,550
‫d'autres normes de formatage des réponses que vous pouvez examiner, telles que Jsend:API

299
00:13:25,550 --> 00:13:27,200
‫ou le protocole Odata JSON.

300
00:13:27,200 --> 00:13:30,330
‫D'accord, et enfin, une

301
00:13:30,330 --> 00:13:34,333
‫API RESTful doit toujours être sans état.

302
00:13:35,800 --> 00:13:37,470
‫Alors, que signifie réellement apatride ?

303
00:13:37,470 --> 00:13:40,720
‫Eh bien, dans une API RESTful sans état, tous

304
00:13:40,720 --> 00:13:43,170
‫les états sont gérés sur

305
00:13:43,170 --> 00:13:45,960
‫le client et non sur le serveur.

306
00:13:45,960 --> 00:13:48,410
‫Et l'état fait simplement référence à un élément de données dans l'application

307
00:13:48,410 --> 00:13:50,120
‫qui peut changer au fil du temps.

308
00:13:50,120 --> 00:13:52,910
‫Par exemple, si un certain utilisateur est connecté

309
00:13:52,910 --> 00:13:55,750
‫ou sur une page avec une liste de

310
00:13:55,750 --> 00:13:56,583
‫plusieurs

311
00:13:56,583 --> 00:13:58,720
‫pages, quelle est la page actuelle.

312
00:13:58,720 --> 00:14:02,230
‫Maintenant, le fait que l'état doit être géré sur le

313
00:14:02,230 --> 00:14:04,150
‫client signifie que chaque

314
00:14:04,150 --> 00:14:06,170
‫requête doit contenir toutes les informations

315
00:14:06,170 --> 00:14:09,910
‫nécessaires pour traiter une certaine requête sur le serveur, d'accord ?

316
00:14:09,910 --> 00:14:12,710
‫Cela a-t-il du sens?

317
00:14:12,710 --> 00:14:15,780
‫Ainsi, le serveur ne devrait jamais avoir

318
00:14:15,780 --> 00:14:17,170
‫à se souvenir

319
00:14:17,170 --> 00:14:21,030
‫de la requête précédente pour traiter la requête en cours.

320
00:14:21,030 --> 00:14:24,010
‫Prenons comme exemple la liste de plusieurs pages.

321
00:14:24,010 --> 00:14:25,906
‫Et disons que de manière récurrente

322
00:14:25,906 --> 00:14:29,670
‫à la page cinq et que vous souhaitez passer à la page six.

323
00:14:29,670 --> 00:14:32,980
‫Nous pourrions donc avoir un point de terminaison simple appelé

324
00:14:32,980 --> 00:14:36,006
‫/tours/nextPage et lui soumettre une demande, n'est-ce pas ?

325
00:14:36,006 --> 00:14:39,710
‫Mais le serveur devrait alors déterminer quelle est la page

326
00:14:40,650 --> 00:14:43,400
‫actuelle et, en fonction de cela, envoyer

327
00:14:43,400 --> 00:14:45,610
‫la page suivante au client.

328
00:14:45,610 --> 00:14:48,450
‫En d'autres termes, le serveur devrait se

329
00:14:48,450 --> 00:14:50,496
‫souvenir de la requête précédente.

330
00:14:50,496 --> 00:14:51,730
‫Il devrait gérer

331
00:14:51,730 --> 00:14:54,950
‫le côté serveur d'état et c'est exactement ce que nous

332
00:14:54,950 --> 00:14:57,640
‫voulons éviter dans les API RESTful, d'accord ?

333
00:14:57,640 --> 00:15:00,260
‫Au lieu de cela, dans ce cas,

334
00:15:00,260 --> 00:15:03,120
‫nous devons créer un point de terminaison /tours/page

335
00:15:03,120 --> 00:15:04,630
‫et y coller le

336
00:15:04,630 --> 00:15:07,550
‫numéro six afin de demander la page numéro six.

337
00:15:07,550 --> 00:15:09,410
‫De cette façon, nous indiquerions ensuite sur

338
00:15:09,410 --> 00:15:11,850
‫le client car sur un client, nous saurions déjà que

339
00:15:11,850 --> 00:15:14,340
‫nous sommes à la page cinq et donc tout ce que

340
00:15:14,340 --> 00:15:15,410
‫nous avions à faire

341
00:15:15,410 --> 00:15:18,320
‫était d'en ajouter un et ensuite de demander la page numéro six.

342
00:15:18,320 --> 00:15:20,750
‫Le serveur n'a donc rien à

343
00:15:20,750 --> 00:15:22,750
‫retenir dans ce cas.

344
00:15:22,750 --> 00:15:23,920
‫Tout ce qu'il a à faire est

345
00:15:23,920 --> 00:15:25,840
‫de renvoyer les données pour la page numéro six comme nous l'avons demandé.

346
00:15:25,840 --> 00:15:27,940
‫Et au fait, l'apatridie et

347
00:15:27,940 --> 00:15:30,840
‫l'état d'état, qui est le contraire, sont

348
00:15:30,840 --> 00:15:33,891
‫des concepts très importants en informatique et en

349
00:15:33,891 --> 00:15:35,760
‫conception d'applications en général.

350
00:15:35,760 --> 00:15:38,560
‫C'est donc une bonne idée de comprendre ce qu'est une

351
00:15:38,560 --> 00:15:40,800
‫API sans état et comment elle fonctionne.

352
00:15:40,800 --> 00:15:44,070
‫Quoi qu'il en soit, ce fut une conférence

353
00:15:44,070 --> 00:15:47,331
‫énorme, mais aussi l'une des plus importantes.

354
00:15:47,331 --> 00:15:50,280
‫Je ne saurais trop insister là-dessus et je pense en fait

355
00:15:50,280 --> 00:15:52,670
‫que vous pouvez le voir, n'est-ce pas ?

356
00:15:52,670 --> 00:15:55,700
‫Quoi qu'il en soit, revenons enfin à notre code.