1
00:00:00,000 --> 00:00:05,340
Maintenant que nous avons

2
00:00:05,340 --> 00:00:11,610
terminé l'implémentation du serveur API REST en utilisant Express et MongoDB dans ce cours,

3
00:00:11,610 --> 00:00:14,990
la prochaine pensée immédiate qui pourrait se produire dans votre esprit est,

4
00:00:14,990 --> 00:00:18,555
puisque nous avons déjà développé les applications clientes,

5
00:00:18,555 --> 00:00:21,460
qu'il s'agisse de l'application Angular, de l'application Ionic

6
00:00:21,460 --> 00:00:25,380
ou de l' Application Native Script dans les cours précédents,

7
00:00:25,380 --> 00:00:29,820
comment intégrer les deux ensemble afin que notre application cliente soit en mesure d'

8
00:00:29,820 --> 00:00:35,780
interagir avec le serveur API REST complet que nous avons développé dans ce cours ?

9
00:00:35,780 --> 00:00:39,605
Donc, c'est ce que nous allons examiner dans cette leçon,

10
00:00:39,605 --> 00:00:44,715
dans cette conférence, et les deux exercices qui suivent cette conférence.

11
00:00:44,715 --> 00:00:46,655
Donc, à la fin de cette leçon,

12
00:00:46,655 --> 00:00:49,295
vous aurez un client Angular que nous

13
00:00:49,295 --> 00:00:52,220
pourrons communiquer avec le serveur que vous venez de développer dans

14
00:00:52,220 --> 00:00:55,265
ce cours et être en mesure de prendre

15
00:00:55,265 --> 00:01:01,410
en charge la vue du client à part entière de notre application.

16
00:01:01,410 --> 00:01:03,860
Ainsi, nous verrons que nous avons développé

17
00:01:03,860 --> 00:01:11,150
l'application complète de bout en bout du côté client jusqu'au côté serveur.

18
00:01:11,150 --> 00:01:13,895
Une approche similaire peut également être utilisée avec

19
00:01:13,895 --> 00:01:17,290
votre client Ionic ou avec votre client de script natif,

20
00:01:17,290 --> 00:01:20,430
étant donné que les scripts ioniques et natifs ont été

21
00:01:20,430 --> 00:01:24,420
développés avec le moteur Angular dans les coulisses.

22
00:01:24,420 --> 00:01:31,100
Ainsi, en effectuant un ensemble similaire d'étapes devrait être en mesure de faire en sorte que votre client Ionic et

23
00:01:31,100 --> 00:01:35,240
votre client de script natif communiquent avec le

24
00:01:35,240 --> 00:01:40,295
serveur d'API de repos Express plus MongoDB que nous avons développé dans ce cours.

25
00:01:40,295 --> 00:01:43,415
Pour intégrer le client et le serveur,

26
00:01:43,415 --> 00:01:44,810
comme nous l'avons réalisé,

27
00:01:44,810 --> 00:01:50,020
notre serveur est déjà implémenté pour prendre en charge l'API REST à part entière.

28
00:01:50,020 --> 00:01:51,695
Du côté client,

29
00:01:51,695 --> 00:01:53,240
qu'il s'agisse du client angulaire, du client

30
00:01:53,240 --> 00:01:55,750
ionique ou du client de script natif,

31
00:01:55,750 --> 00:02:00,740
ils interagissent tous avec le serveur en utilisant les points de terminaison de l'API REST.

32
00:02:00,740 --> 00:02:06,135
Ainsi, lorsque le client envoie la demande au serveur au point de terminaison de

33
00:02:06,135 --> 00:02:10,729
l'API REST, le serveur répondra avec les données JSON correspondantes au client,

34
00:02:10,729 --> 00:02:16,720
et le client peut ensuite utiliser les données JSON pour rendre les vues pour l'utilisateur.

35
00:02:16,720 --> 00:02:22,970
Donc, compte tenu de cette compréhension de la communication entre le client et

36
00:02:22,970 --> 00:02:25,780
le serveur, l'intégration devrait être assez simple.

37
00:02:25,780 --> 00:02:26,960
Mais, bien sûr,

38
00:02:26,960 --> 00:02:30,820
lorsque nous avons développé notre client Angular ou Ionic ou NativeScript,

39
00:02:30,820 --> 00:02:34,990
nous n'avons pas fait la partie d'authentification de l'utilisateur à part entière,

40
00:02:34,990 --> 00:02:38,225
parce que nous n'avions pas cela dans notre serveur JSON.

41
00:02:38,225 --> 00:02:43,250
Maintenant que nous avons l'authentification utilisateur intégrée dans notre côté serveur,

42
00:02:43,250 --> 00:02:47,810
nous devons moderniser nos applications clientes pour

43
00:02:47,810 --> 00:02:52,970
leur permettre d'effectuer l'authentification utilisateur côté serveur, en

44
00:02:52,970 --> 00:02:56,660
publiant les informations de connexion sur le serveur, puis en

45
00:02:56,660 --> 00:03:01,190
obtenant le jeton d'authentification du côté serveur,

46
00:03:01,190 --> 00:03:04,400
et par la suite, en communiquant avec le serveur, y compris

47
00:03:04,400 --> 00:03:08,175
le jeton d'authentification dans l'en-tête des messages de requête.

48
00:03:08,175 --> 00:03:10,130
Donc, tout cela signifie que nous devons faire des

49
00:03:10,130 --> 00:03:12,860
ajustements mineurs à la fois au client et au serveur,

50
00:03:12,860 --> 00:03:15,860
afin que les deux puissent communiquer entre eux.

51
00:03:15,860 --> 00:03:21,020
Un aspect que je n'ai pas traité dans l'exercice précédent,

52
00:03:21,020 --> 00:03:26,445
est la façon dont le serveur gérera les paramètres de requête qui viennent du côté client.

53
00:03:26,445 --> 00:03:27,970
Donc, comme nous l'avons réalisé,

54
00:03:27,970 --> 00:03:31,925
lorsque le côté client envoie une demande pour

55
00:03:31,925 --> 00:03:37,360
un plat en vedette ou un leader en vedette ou une promotion de fonctionnalité,

56
00:03:37,360 --> 00:03:41,665
nous avons vu que l'URL comprend des plats, la

57
00:03:41,665 --> 00:03:45,095
fonction de point d'interrogation est égale à true dans

58
00:03:45,095 --> 00:03:48,840
l'URL de demande qui vient du côté client.

59
00:03:48,840 --> 00:03:51,670
Maintenant, dans les données côté serveur,

60
00:03:51,670 --> 00:03:54,040
nous avons déjà vu que le plat,

61
00:03:54,040 --> 00:03:56,090
la promotion ou le leader,

62
00:03:56,090 --> 00:03:59,835
inclut l'indicateur de fonctionnalité déjà dans les données JSON.

63
00:03:59,835 --> 00:04:02,975
Donc, lorsque cette requête vient du côté serveur,

64
00:04:02,975 --> 00:04:10,285
alors le serveur devrait être capable d'extraire ce paramètre de requête de la requête entrante,

65
00:04:10,285 --> 00:04:16,865
puis faire correctement la requête de

66
00:04:16,865 --> 00:04:24,485
la MongoDB, puis obtenir uniquement les résultats où cet indicateur est défini sur true.

67
00:04:24,485 --> 00:04:26,365
Donc, pour faire cela comme nous l'avons vu,

68
00:04:26,365 --> 00:04:36,380
l'URL qui est utilisée pour envoyer la requête au serveur est /plats ? feature=true.

69
00:04:36,380 --> 00:04:42,365
Donc, c'est ainsi que nous allons fournir les paramètres de requête à notre côté serveur.

70
00:04:42,365 --> 00:04:47,510
Maintenant, en outre, lorsque cette information est reçue du côté serveur,

71
00:04:47,510 --> 00:04:51,890
maintenant, nous avons vu que plus tôt lorsque nous avons fait la demande get côté serveur,

72
00:04:51,890 --> 00:04:56,975
nous avons simplement dit plats trouver et ensuite nous trouverions tous les plats, puis les retourner

73
00:04:56,975 --> 00:05:03,675
lorsque la demande get est envoyée au Dish.RouterRoute/.

74
00:05:03,675 --> 00:05:09,470
La même logique s'applique à la fois au routeur promo et au routeur leader.

75
00:05:09,470 --> 00:05:14,805
Maintenant, lorsque vous incluez un paramètre de requête comme celui-ci dans l'URL,

76
00:05:14,805 --> 00:05:19,270
comment notre côté serveur sera-t-il capable d'extraire ce paramètre de requête ?

77
00:05:19,270 --> 00:05:22,730
Donc, c'est là que lorsque la requête entrante a

78
00:05:22,730 --> 00:05:27,055
ce paramètre de requête attaché à l'URL entrante,

79
00:05:27,055 --> 00:05:31,835
le serveur express le traitera automatiquement et le transformera en

80
00:05:31,835 --> 00:05:38,910
un objet JSON chargé sur un message de requête venant du côté serveur.

81
00:05:38,910 --> 00:05:45,185
Maintenant, cela est disponible côté serveur sous la forme de req.query.

82
00:05:45,185 --> 00:05:49,665
Ainsi, quels que soient les paramètres de requête que vous incluez dans l'URL,

83
00:05:49,665 --> 00:05:56,860
seront transformés en objets JSON correspondants avec les informations définies comme indiqué ici,

84
00:05:56,860 --> 00:06:01,350
puis chargés sur l'objet requête côté serveur.

85
00:06:01,350 --> 00:06:04,670
Ainsi, en utilisant req.query côté serveur,

86
00:06:04,670 --> 00:06:08,105
nous serons en mesure d'obtenir ces paramètres de requête.

87
00:06:08,105 --> 00:06:11,840
Donc, lorsque vous effectuez une requête get côté serveur,

88
00:06:11,840 --> 00:06:18,635
vous dites dishes.find et ensuite vous incluez le req.query dans le find.

89
00:06:18,635 --> 00:06:25,040
Donc, par conséquent, lorsque le MongoDB est interrogé, alors,

90
00:06:25,040 --> 00:06:31,160
seuls les enregistrements ou seuls les documents pour lesquels la vedette est définie sur true seront

91
00:06:31,160 --> 00:06:38,270
extraits de la MongoDB et fournis à nous dans cette méthode get ici,

92
00:06:38,270 --> 00:06:41,625
puis, peuvent être retournés au côté client.

93
00:06:41,625 --> 00:06:49,745
Donc, c'est aussi simple que cela dans la gestion des paramètres de requête côté serveur.

94
00:06:49,745 --> 00:06:55,135
Donc, cette mise à jour, nous allons faire à la fois le routeur plat,

95
00:06:55,135 --> 00:07:01,225
le routeur promo, et le routeur leader côté serveur.

96
00:07:01,225 --> 00:07:04,880
La partie suivante est bien sûr, l'authentification de l'utilisateur.

97
00:07:04,880 --> 00:07:07,530
Ainsi, comme nous l'avons réalisé sur le côté serveur,

98
00:07:07,530 --> 00:07:11,095
nous avons déjà ces points de terminaison API REST,

99
00:07:11,095 --> 00:07:13,780
qui sont utiles pour l'authentification des utilisateurs.

100
00:07:13,780 --> 00:07:18,855
En particulier, lorsque vous publiez sur /users/login,

101
00:07:18,855 --> 00:07:22,040
avec le nom d'utilisateur et le mot de passe,

102
00:07:22,040 --> 00:07:26,140
vous serez en mesure d'authentifier l'utilisateur côté serveur.

103
00:07:26,140 --> 00:07:30,535
Maintenant, lorsque l'utilisateur est authentifié du côté serveur avec succès

104
00:07:30,535 --> 00:07:35,059
, le message de réponse venant du côté serveur inclura

105
00:07:35,059 --> 00:07:43,345
le jeton web JSON dans le corps de la réponse du message de réponse entrant du côté serveur.

106
00:07:43,345 --> 00:07:44,810
Donc, du côté client,

107
00:07:44,810 --> 00:07:49,210
nous devrions être en mesure d'extraire ce jeton et ensuite utiliser ce jeton par la suite.

108
00:07:49,210 --> 00:07:52,700
Ainsi, lorsque le client reçoit le message de réponse

109
00:07:52,700 --> 00:07:57,140
du côté serveur et que l'utilisateur est authentifié avec succès du côté serveur,

110
00:07:57,140 --> 00:07:59,690
le message de réponse contiendra le jeton web JSON,

111
00:07:59,690 --> 00:08:02,290
qui doit être extrait, et par la suite,

112
00:08:02,290 --> 00:08:05,240
le client doit inclure ce jeton web JSON dans

113
00:08:05,240 --> 00:08:10,620
le pour chaque requête sortante du côté client.

114
00:08:10,620 --> 00:08:13,585
Alors, comment pouvons-nous gérer toute cette série d'opérations ?

115
00:08:13,585 --> 00:08:15,800
Maintenant, c'est là que nous allons implémenter

116
00:08:15,800 --> 00:08:20,255
un autre service qui sera utilisé du côté client,

117
00:08:20,255 --> 00:08:21,720
dans notre client Angular,

118
00:08:21,720 --> 00:08:23,810
appelé le service d'authentification,

119
00:08:23,810 --> 00:08:30,185
et c'est là que nous allons gérer l'ensemble des opérations de connexion et de déconnexion.

120
00:08:30,185 --> 00:08:33,850
Maintenant, le processus de déconnexion est assez simple mais,

121
00:08:33,850 --> 00:08:37,840
si nous détruisons le jeton web JSON que nous avons du côté

122
00:08:37,840 --> 00:08:41,160
client, alors le client ne pourra plus accéder au serveur.

123
00:08:41,160 --> 00:08:43,850
Donc, c'est aussi simple que de détruire

124
00:08:43,850 --> 00:08:48,095
le jeton web JSON du côté client pour déconnecter ce client.

125
00:08:48,095 --> 00:08:50,460
Donc, compte tenu de cette compréhension,

126
00:08:50,460 --> 00:08:54,110
voyons les étapes qui sont impliquées dans l'

127
00:08:54,110 --> 00:08:59,760
authentification de l'utilisateur et la gestion de l'authentification de l'utilisateur côté client.

128
00:08:59,760 --> 00:09:03,320
Ainsi, pour gérer l'authentification de l'utilisateur côté client,

129
00:09:03,320 --> 00:09:08,945
le client enverra une demande de poste au point de terminaison /users/login,

130
00:09:08,945 --> 00:09:14,110
et le corps de la requête de publication contiendra le nom d'utilisateur et le mot de passe.

131
00:09:14,110 --> 00:09:16,660
Nous utilisons l'authentification de connexion dans ce cas.

132
00:09:16,660 --> 00:09:18,650
Maintenant, pour l'authentification Facebook à nouveau,

133
00:09:18,650 --> 00:09:22,355
c'est une configuration différente que je ne vais pas discuter en ce moment.

134
00:09:22,355 --> 00:09:26,465
Mais, le corps de la requête comme vous le verrez pour l'authentification locale,

135
00:09:26,465 --> 00:09:28,730
contiendra le nom d'utilisateur et le mot de passe.

136
00:09:28,730 --> 00:09:33,170
Ainsi, lorsque l'utilisateur est authentifié avec succès côté serveur,

137
00:09:33,170 --> 00:09:36,410
le serveur répondra ensuite au

138
00:09:36,410 --> 00:09:41,425
client en incluant le jeton Web JSON dans le message de réponse.

139
00:09:41,425 --> 00:09:46,070
Ainsi, lorsque le client reçoit le message de réponse du côté serveur,

140
00:09:46,070 --> 00:09:49,790
le client devra capturer ce jeton web JSON,

141
00:09:49,790 --> 00:09:55,025
puis enregistrer le jeton web JSON dans le stockage local côté client. Par

142
00:09:55,025 --> 00:10:01,250
la suite, le client doit inclure ce jeton dans chaque demande sortante.

143
00:10:01,250 --> 00:10:04,455
Alors, comment cela est-il accompli du côté client ?

144
00:10:04,455 --> 00:10:06,155
Tout d'abord, bien sûr,

145
00:10:06,155 --> 00:10:11,980
vous devez enregistrer le jeton Web JSON entrant dans le stockage local,

146
00:10:11,980 --> 00:10:16,790
et cela se fait dans le service d'authentification que nous allons implémenter du côté client.

147
00:10:16,790 --> 00:10:19,975
Maintenant, pour chaque requête sortante,

148
00:10:19,975 --> 00:10:22,850
le client inclura ce jeton dans l'en-tête,

149
00:10:22,850 --> 00:10:27,100
l'en-tête d'autorisation de la demande sortante.

150
00:10:27,100 --> 00:10:28,555
Maintenant, comment cela est-il accompli ?

151
00:10:28,555 --> 00:10:33,935
Donc, c'est là que nous allons prendre l'aide d'un intercepteur HTTP,

152
00:10:33,935 --> 00:10:37,265
que le HttpClient dans Angular prend en charge.

153
00:10:37,265 --> 00:10:39,675
Ainsi, avec l'intercepteur HTTP,

154
00:10:39,675 --> 00:10:42,305
l'intercepteur nous permet d'intercepter

155
00:10:42,305 --> 00:10:45,875
chaque message de requête sortant ou même d'

156
00:10:45,875 --> 00:10:50,010
intercepter chaque message de réponse entrant si vous le souhaitez.

157
00:10:50,010 --> 00:10:52,175
Mais dans l'application Angular,

158
00:10:52,175 --> 00:10:56,215
nous allons implémenter l'intercepteur de requête,

159
00:10:56,215 --> 00:10:59,540
ce que je vais illustrer dans l'exercice plus tard.

160
00:10:59,540 --> 00:11:02,460
Dans l'intercepteur de requête HTTP,

161
00:11:02,460 --> 00:11:04,375
lorsque le message de requête est intercepté,

162
00:11:04,375 --> 00:11:09,915
chaque message de requête sortant sera intercepté, puis le jeton Web JSON

163
00:11:09,915 --> 00:11:15,650
sera inséré dans l'en-tête d'autorisation du message de requête.

164
00:11:15,650 --> 00:11:20,290
Ensuite, le message de requête serait transmis sur le côté serveur.

165
00:11:20,290 --> 00:11:26,825
Ainsi, chaque requête sortante après que l'utilisateur est authentifié côté serveur,

166
00:11:26,825 --> 00:11:30,620
chaque requête sortante du côté client portera

167
00:11:30,620 --> 00:11:35,590
le jeton web JSON dans l'en-tête d'autorisation de la demande sortante.

168
00:11:35,590 --> 00:11:38,600
Maintenant, une fois que le client se déconnecte,

169
00:11:38,600 --> 00:11:42,595
le jeton Web JSON sera détruit du côté client. Par

170
00:11:42,595 --> 00:11:47,215
conséquent, par la suite, les requêtes sortantes ne contiendront plus le jeton web

171
00:11:47,215 --> 00:11:50,160
JSON, car le jeton web JSON n'existe pas du côté client.

172
00:11:50,160 --> 00:11:53,240
Ainsi, par conséquent, l'utilisateur perd l'authentification.

173
00:11:53,240 --> 00:12:00,030
Donc, c'est ainsi que nous allons gérer le processus de connexion et de déconnexion côté client,

174
00:12:00,030 --> 00:12:02,290
en communiquant avec le serveur,

175
00:12:02,290 --> 00:12:04,225
puis obtenir le jeton web JSON,

176
00:12:04,225 --> 00:12:08,845
puis en incluant le jeton web JSON dans chaque requête sortante.

177
00:12:08,845 --> 00:12:14,250
Maintenant, avec cette compréhension de la façon dont le client et le serveur vont interagir,

178
00:12:14,250 --> 00:12:18,205
passons maintenant aux deux exercices suivants. Tout d'

179
00:12:18,205 --> 00:12:22,540
abord, nous allons mettre à jour le côté serveur avec quelques ajouts,

180
00:12:22,540 --> 00:12:28,220
afin qu'il puisse bien s'intégrer avec notre site client. Par la

181
00:12:28,220 --> 00:12:32,750
suite, nous mettrons à jour le côté client ou plutôt je vous donnerai

182
00:12:32,750 --> 00:12:36,215
une application cliente à part entière que j'ai

183
00:12:36,215 --> 00:12:40,795
prise du cours Angular antérieur, puis je la mettrai à jour, ce

184
00:12:40,795 --> 00:12:45,875
qui nous donne également la possibilité d'utiliser des intercepteurs HTTP

185
00:12:45,875 --> 00:12:51,595
sur les requêtes sortantes et les messages de réponse entrants.

186
00:12:51,595 --> 00:12:56,090
Donc, nous allons traiter ces deux exercices dans les deux prochains exercices,

187
00:12:56,090 --> 00:12:58,370
et à la fin de celui-ci, vous comprendrez comment

188
00:12:58,370 --> 00:13:02,530
intégrer votre client et le côté serveur.