1
00:00:03,650 --> 00:00:06,795
Maintenant que nous avons terminé

2
00:00:06,795 --> 00:00:11,395
l'implémentation du serveur API REST en utilisant Express et MongoDB dans ce cours,

3
00:00:11,395 --> 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:20,490
puisque nous avons déjà développé les applications clientes dans les cours précédents,

5
00:00:20,490 --> 00:00:24,930
comment intégrer les deux ensemble afin que notre est capable d'

6
00:00:24,930 --> 00:00:30,880
interagir avec le serveur API REST complet que nous avons développé dans ce cours ?

7
00:00:30,880 --> 00:00:33,820
Donc, c'est ce que nous allons examiner dans

8
00:00:33,820 --> 00:00:39,820
cette conférence et les deux exercices qui suivent cette conférence.

9
00:00:39,820 --> 00:00:41,770
Donc, à la fin de cette leçon,

10
00:00:41,770 --> 00:00:44,390
vous aurez React Client qui sera

11
00:00:44,390 --> 00:00:47,330
en mesure de communiquer avec le serveur que vous venez de développer dans

12
00:00:47,330 --> 00:00:50,345
ce cours et sera en mesure de prendre

13
00:00:50,345 --> 00:00:56,510
en charge la vue du client à part entière de notre application.

14
00:00:56,510 --> 00:00:58,970
De cette façon, nous verrons que nous avons développé

15
00:00:58,970 --> 00:01:02,565
l'

16
00:01:02,565 --> 00:01:07,795
application complète de bout en bout du côté client jusqu'au côté serveur dans ce cours.

17
00:01:07,795 --> 00:01:10,910
Pour intégrer le client et le serveur,

18
00:01:10,910 --> 00:01:13,670
comme nous l'avons réalisé, notre serveur est déjà

19
00:01:13,670 --> 00:01:17,525
implémenté pour prendre en charge l'API REST à part entière.

20
00:01:17,525 --> 00:01:19,220
Du côté client,

21
00:01:19,220 --> 00:01:20,720
qu'il s'agisse du client angulaire, du client

22
00:01:20,720 --> 00:01:23,340
ionique ou du client de script natif,

23
00:01:23,340 --> 00:01:28,240
ils interagissent tous avec le serveur en utilisant les points de terminaison de l'API REST.

24
00:01:28,240 --> 00:01:33,630
Ainsi, lorsque le client envoie la demande au serveur au point de terminaison de l'API REST,

25
00:01:33,630 --> 00:01:38,190
le serveur répondra avec les données JSON correspondantes au client.

26
00:01:38,190 --> 00:01:44,225
Le client peut alors utiliser les données JSON pour rendre les vues pour l'utilisateur.

27
00:01:44,225 --> 00:01:50,450
Donc, compte tenu de cette compréhension de la communication entre le client et

28
00:01:50,450 --> 00:01:53,745
le serveur, l'intégration devrait être assez simple.

29
00:01:53,745 --> 00:01:58,475
Maintenant que nous avons l'authentification utilisateur intégrée dans notre côté serveur,

30
00:01:58,475 --> 00:02:03,330
nous devons moderniser nos applications clientes pour

31
00:02:03,330 --> 00:02:08,400
leur permettre d'effectuer l'authentification utilisateur côté serveur en

32
00:02:08,400 --> 00:02:12,200
publiant les informations de connexion sur le serveur puis en

33
00:02:12,200 --> 00:02:16,010
obtenant le jeton d'authentification

34
00:02:16,010 --> 00:02:19,120
du côté serveur et ensuite communiquer avec le serveur,

35
00:02:19,120 --> 00:02:23,700
y compris le jeton d'authentification dans l'en-tête des messages de requête.

36
00:02:23,700 --> 00:02:27,050
Donc, tout cela signifie que nous devons faire des ajustements mineurs à

37
00:02:27,050 --> 00:02:31,345
la fois au client et au serveur afin que les deux puissent communiquer entre eux.

38
00:02:31,345 --> 00:02:36,530
Un aspect que je n'ai pas traité dans l'exercice précédent

39
00:02:36,530 --> 00:02:41,970
est la façon dont le serveur gérera les paramètres de requête qui viennent du côté client.

40
00:02:41,970 --> 00:02:43,480
Donc, comme nous l'avons réalisé,

41
00:02:43,480 --> 00:02:47,450
lorsque le côté client envoie une demande pour

42
00:02:47,450 --> 00:02:53,035
un plat en vedette ou un leader en vedette ou une promotion en vedette,

43
00:02:53,035 --> 00:02:55,910
nous avons vu que l'URL inclut, la

44
00:02:55,910 --> 00:02:59,590
fonction de point d'interrogation plats est égale à

45
00:02:59,590 --> 00:03:04,370
true dans l'URL de demande qui vient du côté client.

46
00:03:04,370 --> 00:03:07,210
Maintenant, dans les données du côté serveur,

47
00:03:07,210 --> 00:03:09,585
nous avons déjà vu que le plat,

48
00:03:09,585 --> 00:03:15,370
la promotion ou le leader inclut le drapeau en vedette déjà dans les données JSON.

49
00:03:15,370 --> 00:03:18,649
Donc, lorsque cette requête vient du côté serveur,

50
00:03:18,649 --> 00:03:21,394
alors le serveur devrait être capable d'extraire

51
00:03:21,394 --> 00:03:26,765
ce paramètre de requête de la requête entrante, puis

52
00:03:26,765 --> 00:03:32,390
faire correctement la requête de

53
00:03:32,390 --> 00:03:39,950
la MongoDB, puis obtenir uniquement les résultats où cet indicateur est défini sur true.

54
00:03:39,950 --> 00:03:41,740
Donc, pour ce faire, comme nous l'avons vu,

55
00:03:41,740 --> 00:03:47,075
l'URL qui est utilisée pour envoyer la requête au serveur est,

56
00:03:47,075 --> 00:03:52,030
barre oblique plats point d'interrogation en vedette est égale à true.

57
00:03:52,030 --> 00:03:57,905
Donc, c'est ainsi que nous allons fournir les paramètres de requête à notre côté serveur.

58
00:03:57,905 --> 00:04:02,610
Maintenant, en outre, lorsque cette information est reçue du côté serveur,

59
00:04:02,610 --> 00:04:07,430
maintenant nous avons vu que plus tôt quand nous avons fait la demande get du côté serveur,

60
00:04:07,430 --> 00:04:10,190
nous avons simplement dit plats trouver et puis nous trouverions

61
00:04:10,190 --> 00:04:13,135
tous les plats, puis les retourner lorsque

62
00:04:13,135 --> 00:04:19,745
la demande get est envoyée à la barre de routeur plat .

63
00:04:19,745 --> 00:04:25,185
La même logique s'applique à la fois au routeur promo et au routeur leader.

64
00:04:25,185 --> 00:04:30,339
Maintenant, lorsque vous incluez un paramètre de requête comme celui-ci dans l'URL,

65
00:04:30,339 --> 00:04:34,695
comment notre côté serveur sera-t-il capable d'extraire ce paramètre de requête ?

66
00:04:34,695 --> 00:04:35,980
Donc, c'est là que,

67
00:04:35,980 --> 00:04:42,590
lorsque la requête entrante a ce paramètre de requête attaché à l'URL entrante,

68
00:04:42,590 --> 00:04:47,375
le serveur express le traitera automatiquement et le transformera en

69
00:04:47,375 --> 00:04:54,445
un objet JSON chargé sur un message de requête venant du côté serveur.

70
00:04:54,445 --> 00:05:00,710
Maintenant, cela est disponible côté serveur sous la forme de req.query.

71
00:05:00,710 --> 00:05:06,545
Ainsi, quels que soient les paramètres de requête que vous incluez dans l'URL seront transformés en

72
00:05:06,545 --> 00:05:11,480
objets JSON correspondants avec les informations définies

73
00:05:11,480 --> 00:05:16,880
ici, puis chargés sur l'objet requête côté serveur.

74
00:05:16,880 --> 00:05:19,940
Ainsi, en utilisant req.query côté serveur,

75
00:05:19,940 --> 00:05:23,625
nous serons en mesure d'obtenir ces paramètres de requête.

76
00:05:23,625 --> 00:05:27,935
Donc, lorsque vous effectuez une requête get du côté serveur, vous dites

77
00:05:27,935 --> 00:05:34,115
dishes.find et ensuite vous incluez le req.query dans le find il.

78
00:05:34,115 --> 00:05:38,960
Ainsi, lorsque le MongoDB est

79
00:05:38,960 --> 00:05:44,120
interrogé, seuls les enregistrements ou seuls les documents pour

80
00:05:44,120 --> 00:05:50,390
lesquels la vedette est définie sur true seront extraits de la MongoDB et fournis à

81
00:05:50,390 --> 00:05:57,020
nous dans cette méthode get ici et peuvent ensuite être retournés au côté client.

82
00:05:57,020 --> 00:06:05,270
Donc, c'est aussi simple que cela dans la gestion des paramètres de requête côté serveur.

83
00:06:05,270 --> 00:06:10,645
Donc, cette mise à jour, nous allons faire à la fois le routeur plat,

84
00:06:10,645 --> 00:06:16,880
le routeur promo, et le routeur leader côté serveur.

85
00:06:16,880 --> 00:06:18,430
La partie suivante est,

86
00:06:18,430 --> 00:06:20,545
bien sûr, l'authentification de l'utilisateur.

87
00:06:20,545 --> 00:06:22,060
Donc, comme nous l'avons réalisé,

88
00:06:22,060 --> 00:06:24,150
du côté serveur, nous avons déjà

89
00:06:24,150 --> 00:06:29,450
ces points de terminaison API REST qui sont utiles pour l'authentification utilisateur,

90
00:06:29,450 --> 00:06:33,260
en particulier lorsque vous faites un post pour slash utilisateurs

91
00:06:33,260 --> 00:06:37,100
slash connexion avec le nom d'utilisateur et le mot de passe,

92
00:06:37,100 --> 00:06:41,675
alors vous serez en mesure d'authentifier l'utilisateur sur le serveur côté.

93
00:06:41,675 --> 00:06:46,080
Maintenant, lorsque l'utilisateur est authentifié sur le côté serveur avec succès

94
00:06:46,080 --> 00:06:50,584
, le message de réponse provenant du côté serveur inclura

95
00:06:50,584 --> 00:06:58,880
le jeton Web JSON dans le corps de la réponse du message de réponse entrant du côté serveur.

96
00:06:58,880 --> 00:07:00,350
Donc, du côté client,

97
00:07:00,350 --> 00:07:04,700
nous devrions être en mesure d'extraire ce jeton et ensuite utiliser ce jeton par la suite.

98
00:07:04,700 --> 00:07:08,210
Ainsi, lorsque le client reçoit le message de réponse

99
00:07:08,210 --> 00:07:12,560
du côté serveur et que l'utilisateur est authentifié avec succès côté serveur,

100
00:07:12,560 --> 00:07:15,220
le message de réponse contiendra le jeton Web JSON,

101
00:07:15,220 --> 00:07:16,950
qui doit être extrait,

102
00:07:16,950 --> 00:07:20,780
et par la suite, le client doit inclure ce jeton Web JSON dans

103
00:07:20,780 --> 00:07:26,200
le pour chaque requête sortante du côté client.

104
00:07:26,200 --> 00:07:31,205
Pour ce faire, enregistrez le jeton Web JSON dans le stockage local.

105
00:07:31,205 --> 00:07:35,155
Par la suite, pour chaque demande de récupération que nous

106
00:07:35,155 --> 00:07:40,365
émettons, nous pouvons configurer l'en-tête d'autorisation pour contenir le jeton Web JSON.

107
00:07:40,365 --> 00:07:43,815
Maintenant, le processus de déconnexion est assez simple,

108
00:07:43,815 --> 00:07:47,865
si nous détruisons le jeton Web JSON que nous avons du côté client,

109
00:07:47,865 --> 00:07:51,210
alors le client ne sera plus en mesure d'accéder au serveur.

110
00:07:51,210 --> 00:07:53,930
Donc, c'est aussi simple que de détruire

111
00:07:53,930 --> 00:07:58,180
le jeton Web JSON du côté client pour déconnecter ce client.

112
00:07:58,180 --> 00:08:00,530
Donc, compte tenu de cette compréhension,

113
00:08:00,530 --> 00:08:04,175
voyons les étapes qui sont impliquées dans l'

114
00:08:04,175 --> 00:08:09,840
authentification de l'utilisateur sur la gestion de l'authentification de l'utilisateur côté client.

115
00:08:09,840 --> 00:08:13,085
Ainsi, pour gérer l'authentification de l'utilisateur côté client,

116
00:08:13,085 --> 00:08:19,000
le client enverra une demande de poste au point de terminaison de connexion des utilisateurs barre oblique,

117
00:08:19,000 --> 00:08:24,190
et le corps de la demande de publication contiendra le nom d'utilisateur et le mot de passe.

118
00:08:24,190 --> 00:08:26,720
Nous utilisons l'authentification de connexion dans ce cas.

119
00:08:26,720 --> 00:08:28,695
Maintenant, pour l'authentification Facebook, encore une fois,

120
00:08:28,695 --> 00:08:32,425
c'est une configuration différente que je ne vais pas discuter en ce moment.

121
00:08:32,425 --> 00:08:35,570
Mais le corps de la requête comme vous le voyez pour l'

122
00:08:35,570 --> 00:08:38,780
authentification locale contiendra le nom d'utilisateur et le mot de passe.

123
00:08:38,780 --> 00:08:43,220
Ainsi, lorsque l'utilisateur est authentifié avec succès côté serveur,

124
00:08:43,220 --> 00:08:46,460
le serveur répondra ensuite au

125
00:08:46,460 --> 00:08:51,490
client en incluant le jeton Web JSON dans le message de réponse.

126
00:08:51,490 --> 00:08:56,150
Ainsi, lorsque le client reçoit le message de réponse du côté serveur,

127
00:08:56,150 --> 00:09:00,320
le client devra capturer ce jeton Web JSON, puis

128
00:09:00,320 --> 00:09:05,080
enregistrer le jeton Web JSON dans le stockage local côté client. Par

129
00:09:05,080 --> 00:09:11,300
la suite, le client doit inclure ce jeton dans chaque demande sortante.

130
00:09:11,300 --> 00:09:14,495
Alors, comment cela est-il accompli du côté client ?

131
00:09:14,495 --> 00:09:20,285
Tout d'abord, nous devons enregistrer le jeton Web JSON dans le stockage local.

132
00:09:20,285 --> 00:09:25,670
Maintenant, cela est accompli dans le créateur d'action qui gère le processus de connexion de l'utilisateur.

133
00:09:25,670 --> 00:09:32,685
Ainsi, lorsque le message est fait sur le serveur à partir du créateur d'induction côté client

134
00:09:32,685 --> 00:09:36,020
, le message de réponse contiendra le jeton,

135
00:09:36,020 --> 00:09:41,540
et ce jeton est enregistré dans le créateur d'action qui gère le processus de connexion de l'utilisateur.

136
00:09:41,540 --> 00:09:45,875
Maintenant, quand une requête de récupération est faite,

137
00:09:45,875 --> 00:09:52,829
alors nous pouvons facilement définir l'en-tête d'autorisation dans la requête de récupération sortante.

138
00:09:52,829 --> 00:09:56,005
Maintenant, une fois que le client se déconnecte,

139
00:09:56,005 --> 00:09:59,930
le jeton Web JSON sera détruit du côté client.

140
00:09:59,930 --> 00:10:03,050
Par la suite, les requêtes sortantes ne contiendront

141
00:10:03,050 --> 00:10:07,490
plus le jeton Web JSON car le jeton Web JSON n'existe pas du côté client.

142
00:10:07,490 --> 00:10:10,790
Ainsi, l'utilisateur perd l'authentification.

143
00:10:10,790 --> 00:10:17,455
Donc, c'est ainsi que nous allons gérer la connexion et le processus de déconnexion du côté client.

144
00:10:17,455 --> 00:10:21,890
En communiquant avec le serveur, puis obtenez le jeton Web JSON

145
00:10:21,890 --> 00:10:26,185
, puis en incluant le jeton Web JSON dans chaque requête sortante.

146
00:10:26,185 --> 00:10:31,570
Maintenant, avec cette compréhension de la façon dont le client et le serveur vont interagir,

147
00:10:31,570 --> 00:10:35,540
passons maintenant aux deux exercices suivants. Tout d'

148
00:10:35,540 --> 00:10:40,410
abord, nous allons mettre à jour le côté serveur avec quelques ajouts afin

149
00:10:40,410 --> 00:10:45,550
qu'il puisse bien s'intégrer avec notre côté client.

150
00:10:45,550 --> 00:10:50,075
Par la suite, nous mettrons à jour le côté client ou plutôt je vous donnerai

151
00:10:50,075 --> 00:10:54,200
une application client à part entière que j'ai prise

152
00:10:54,200 --> 00:10:58,875
de la force de réaction antérieure et l'ai adaptée, mise à jour.

153
00:10:58,875 --> 00:11:03,080
Donc, nous allons traiter ces deux exercices dans les deux prochains exercices,

154
00:11:03,080 --> 00:11:09,460
et à la fin de celui-ci, vous comprendrez comment intégrer votre côté client et serveur.