Maintenant que nous avons terminé
l'implémentation du serveur API REST en utilisant Express et MongoDB dans ce cours,
la prochaine pensée immédiate qui pourrait se produire dans votre esprit est,
puisque nous avons déjà développé les applications clientes dans les cours précédents,
comment intégrer les deux ensemble afin que notre est capable d'
interagir avec le serveur API REST complet que nous avons développé dans ce cours ?
Donc, c'est ce que nous allons examiner dans
cette conférence et les deux exercices qui suivent cette conférence.
Donc, à la fin de cette leçon,
vous aurez React Client qui sera
en mesure de communiquer avec le serveur que vous venez de développer dans
ce cours et sera en mesure de prendre
en charge la vue du client à part entière de notre application.
De cette façon, nous verrons que nous avons développé
l'
application complète de bout en bout du côté client jusqu'au côté serveur dans ce cours.
Pour intégrer le client et le serveur,
comme nous l'avons réalisé, notre serveur est déjà
implémenté pour prendre en charge l'API REST à part entière.
Du côté client,
qu'il s'agisse du client angulaire, du client
ionique ou du client de script natif,
ils interagissent tous avec le serveur en utilisant les points de terminaison de l'API REST.
Ainsi, lorsque le client envoie la demande au serveur au point de terminaison de l'API REST,
le serveur répondra avec les données JSON correspondantes au client.
Le client peut alors utiliser les données JSON pour rendre les vues pour l'utilisateur.
Donc, compte tenu de cette compréhension de la communication entre le client et
le serveur, l'intégration devrait être assez simple.
Maintenant que nous avons l'authentification utilisateur intégrée dans notre côté serveur,
nous devons moderniser nos applications clientes pour
leur permettre d'effectuer l'authentification utilisateur côté serveur en
publiant les informations de connexion sur le serveur puis en
obtenant le jeton d'authentification
du côté serveur et ensuite communiquer avec le serveur,
y compris le jeton d'authentification dans l'en-tête des messages de requête.
Donc, tout cela signifie que nous devons faire des ajustements mineurs à
la fois au client et au serveur afin que les deux puissent communiquer entre eux.
Un aspect que je n'ai pas traité dans l'exercice précédent
est la façon dont le serveur gérera les paramètres de requête qui viennent du côté client.
Donc, comme nous l'avons réalisé,
lorsque le côté client envoie une demande pour
un plat en vedette ou un leader en vedette ou une promotion en vedette,
nous avons vu que l'URL inclut, la
fonction de point d'interrogation plats est égale à
true dans l'URL de demande qui vient du côté client.
Maintenant, dans les données du côté serveur,
nous avons déjà vu que le plat,
la promotion ou le leader inclut le drapeau en vedette déjà dans les données JSON.
Donc, lorsque cette requête vient du côté serveur,
alors le serveur devrait être capable d'extraire
ce paramètre de requête de la requête entrante, puis
faire correctement la requête de
la MongoDB, puis obtenir uniquement les résultats où cet indicateur est défini sur true.
Donc, pour ce faire, comme nous l'avons vu,
l'URL qui est utilisée pour envoyer la requête au serveur est,
barre oblique plats point d'interrogation en vedette est égale à true.
Donc, c'est ainsi que nous allons fournir les paramètres de requête à notre côté serveur.
Maintenant, en outre, lorsque cette information est reçue du côté serveur,
maintenant nous avons vu que plus tôt quand nous avons fait la demande get du côté serveur,
nous avons simplement dit plats trouver et puis nous trouverions
tous les plats, puis les retourner lorsque
la demande get est envoyée à la barre de routeur plat .
La même logique s'applique à la fois au routeur promo et au routeur leader.
Maintenant, lorsque vous incluez un paramètre de requête comme celui-ci dans l'URL,
comment notre côté serveur sera-t-il capable d'extraire ce paramètre de requête ?
Donc, c'est là que,
lorsque la requête entrante a ce paramètre de requête attaché à l'URL entrante,
le serveur express le traitera automatiquement et le transformera en
un objet JSON chargé sur un message de requête venant du côté serveur.
Maintenant, cela est disponible côté serveur sous la forme de req.query.
Ainsi, quels que soient les paramètres de requête que vous incluez dans l'URL seront transformés en
objets JSON correspondants avec les informations définies
ici, puis chargés sur l'objet requête côté serveur.
Ainsi, en utilisant req.query côté serveur,
nous serons en mesure d'obtenir ces paramètres de requête.
Donc, lorsque vous effectuez une requête get du côté serveur, vous dites
dishes.find et ensuite vous incluez le req.query dans le find il.
Ainsi, lorsque le MongoDB est
interrogé, seuls les enregistrements ou seuls les documents pour
lesquels la vedette est définie sur true seront extraits de la MongoDB et fournis à
nous dans cette méthode get ici et peuvent ensuite être retournés au côté client.
Donc, c'est aussi simple que cela dans la gestion des paramètres de requête côté serveur.
Donc, cette mise à jour, nous allons faire à la fois le routeur plat,
le routeur promo, et le routeur leader côté serveur.
La partie suivante est,
bien sûr, l'authentification de l'utilisateur.
Donc, comme nous l'avons réalisé,
du côté serveur, nous avons déjà
ces points de terminaison API REST qui sont utiles pour l'authentification utilisateur,
en particulier lorsque vous faites un post pour slash utilisateurs
slash connexion avec le nom d'utilisateur et le mot de passe,
alors vous serez en mesure d'authentifier l'utilisateur sur le serveur côté.
Maintenant, lorsque l'utilisateur est authentifié sur le côté serveur avec succès
, le message de réponse provenant du côté serveur inclura
le jeton Web JSON dans le corps de la réponse du message de réponse entrant du côté serveur.
Donc, du côté client,
nous devrions être en mesure d'extraire ce jeton et ensuite utiliser ce jeton par la suite.
Ainsi, lorsque le client reçoit le message de réponse
du côté serveur et que l'utilisateur est authentifié avec succès côté serveur,
le message de réponse contiendra le jeton Web JSON,
qui doit être extrait,
et par la suite, le client doit inclure ce jeton Web JSON dans
le pour chaque requête sortante du côté client.
Pour ce faire, enregistrez le jeton Web JSON dans le stockage local.
Par la suite, pour chaque demande de récupération que nous
émettons, nous pouvons configurer l'en-tête d'autorisation pour contenir le jeton Web JSON.
Maintenant, le processus de déconnexion est assez simple,
si nous détruisons le jeton Web JSON que nous avons du côté client,
alors le client ne sera plus en mesure d'accéder au serveur.
Donc, c'est aussi simple que de détruire
le jeton Web JSON du côté client pour déconnecter ce client.
Donc, compte tenu de cette compréhension,
voyons les étapes qui sont impliquées dans l'
authentification de l'utilisateur sur la gestion de l'authentification de l'utilisateur côté client.
Ainsi, pour gérer l'authentification de l'utilisateur côté client,
le client enverra une demande de poste au point de terminaison de connexion des utilisateurs barre oblique,
et le corps de la demande de publication contiendra le nom d'utilisateur et le mot de passe.
Nous utilisons l'authentification de connexion dans ce cas.
Maintenant, pour l'authentification Facebook, encore une fois,
c'est une configuration différente que je ne vais pas discuter en ce moment.
Mais le corps de la requête comme vous le voyez pour l'
authentification locale contiendra le nom d'utilisateur et le mot de passe.
Ainsi, lorsque l'utilisateur est authentifié avec succès côté serveur,
le serveur répondra ensuite au
client en incluant le jeton Web JSON dans le message de réponse.
Ainsi, lorsque le client reçoit le message de réponse du côté serveur,
le client devra capturer ce jeton Web JSON, puis
enregistrer le jeton Web JSON dans le stockage local côté client. Par
la suite, le client doit inclure ce jeton dans chaque demande sortante.
Alors, comment cela est-il accompli du côté client ?
Tout d'abord, nous devons enregistrer le jeton Web JSON dans le stockage local.
Maintenant, cela est accompli dans le créateur d'action qui gère le processus de connexion de l'utilisateur.
Ainsi, lorsque le message est fait sur le serveur à partir du créateur d'induction côté client
, le message de réponse contiendra le jeton,
et ce jeton est enregistré dans le créateur d'action qui gère le processus de connexion de l'utilisateur.
Maintenant, quand une requête de récupération est faite,
alors nous pouvons facilement définir l'en-tête d'autorisation dans la requête de récupération sortante.
Maintenant, une fois que le client se déconnecte,
le jeton Web JSON sera détruit du côté client.
Par la suite, les requêtes sortantes ne contiendront
plus le jeton Web JSON car le jeton Web JSON n'existe pas du côté client.
Ainsi, l'utilisateur perd l'authentification.
Donc, c'est ainsi que nous allons gérer la connexion et le processus de déconnexion du côté client.
En communiquant avec le serveur, puis obtenez le jeton Web JSON
, puis en incluant le jeton Web JSON dans chaque requête sortante.
Maintenant, avec cette compréhension de la façon dont le client et le serveur vont interagir,
passons maintenant aux deux exercices suivants. Tout d'
abord, nous allons mettre à jour le côté serveur avec quelques ajouts afin
qu'il puisse bien s'intégrer avec notre côté client.
Par la suite, nous mettrons à jour le côté client ou plutôt je vous donnerai
une application client à part entière que j'ai prise
de la force de réaction antérieure et l'ai adaptée, mise à jour.
Donc, nous allons traiter ces deux exercices dans les deux prochains exercices,
et à la fin de celui-ci, vous comprendrez comment intégrer votre côté client et serveur.