Dans cette leçon en français, l’instructeur montre pas à pas comment créer un serveur HTTP avec Express.js. Après avoir rappelé l’installation d’Express et de nodemon, il importe le module, crée une instance `app`, et lance le serveur avec `app.listen(3000, callback)`. Il explique le rôle du callback et montre le premier test dans le navigateur qui renvoie « Cannot GET » faute de route. Il introduit la notion de route – combinaison d’une méthode HTTP (GET, POST, PUT, DELETE) et d’un chemin – et montre comment déclarer des routes simples avec `app.get('/', (req, res) => {...})`, en utilisant `req` et `res`. Il détaille l’envoi de réponses avec `res.send()` (qui termine la requête) et `res.end()`. Il crée plusieurs routes, change les méthodes, et utilise Postman pour tester les requêtes POST, PUT et DELETE. Il décrit l’ordre de correspondance des routes : Express parcourt les routes dans l’ordre de déclaration et s’arrête à la première correspondance, sauf si l’on invoque `next()` pour passer à la suivante. Il montre comment chaîner plusieurs routes sur le même chemin avec `next`. Ensuite, il introduit les middleware : fonctions qui reçoivent `req` et `res` et peuvent modifier la requête ou la réponse. Il montre comment attacher un middleware à une route spécifique en le plaçant comme deuxième argument, et comment le rendre global avec `app.use(middleware)`. Il teste le comportement du middleware global, même lorsqu’aucune route ne correspond, et souligne l’importance d’appeler `next()` pour laisser la suite s’exécuter. La vidéo se conclut en récapitulant les concepts clés – routes, méthodes HTTP, middleware, `next` – et encourage les apprenants à pratiquer.
Chapters
Bonjour à tous et bienvenue dans cette nouvelle leçon sur le framework Express. Aujourd'hui, nous allons voir comment monter un serveur, comment écouter nos premières requêtes et envoyer les réponses aux clients. Nous allons aussi voir la notion de routes et de middleware. La dernière fois, nous avons vu comment installer le module Express et l'utilitaire nodemon qui permet de redémarrer automatiquement le serveur après chaque changement. Nous allons commencer par démarrer NodeMon. Désormais, après la détection de chaque changement sur le fichier principal app.js, NodeMon se chargera de redémarrer le serveur automatiquement. La première opération consiste à importer Express grâce à cette instruction qui invoque le module Express. Ensuite, nous allons créer une instance Express que nous appellerons app. C'est cette instance qui sera traitée dans la suite du code. Cela revient à créer un serveur HTTP. Maintenant, on va écouter les requêtes à l'aide de la méthode listen et comme argument on va spécifier le numéro de port. Je mettrai par exemple le port 3000. En fait, vous êtes libre de choisir n'importe quel port du moment où ce n'est pas utilisé pour éviter tout conflit. Après enregistrement, on constate que notre demande fait son travail et recharge automatiquement le serveur. Il est utile d'afficher un message sur la console suite au redémarrage du serveur. Alors la méthode listen accepte un deuxième argument qui est une fonction de callback. Alors on a bien sur la console un message qui indique que le serveur commence à écouter les requêtes. Faisons un test sur le navigateur en spécifiant le port 3000. On tape l'adresse localhost et on spécifie le port. On voit que le navigateur nous répond par Cannot GET. Il s'agit d'une petite erreur qui est due au fait que nous n'avons pas encore spécifié de route. Dans l'environnement Express, une route correspond à la combinaison de la méthode HTTP et le chemin de la ressource demandée. Par exemple, on invoque l'instance Express app et on lui associe une méthode HTTP. On mettra par exemple GET. Après, on va spécifier le chemin de la ressource en guise de premier argument. On mettra par exemple le slash. Alors, la combinaison du chemin et de la méthode constitue ce qu'on appelle une route. Maintenant, si jamais on demande une ressource sur la racine du serveur, il va s'ensuivre un traitement. C'est ce qu'on va spécifier dans le deuxième argument. On mettra une fonction fléchée et dedans on va mettre par exemple un message. On va juste afficher sur la console le message GET. Nous avons juste le message serveur en écoute, mais quand j'exécuterai la requête et demanderai la ressource, vous allez voir que le message GET va s'ajouter. Alors nous avons bien GET qui est ajouté et vous avez constaté que le navigateur tourne toujours parce qu'on n'a pas encore mis fin au processus requête-réponse, ce qui est tout à fait normal dans ce cas. Normalement, à la fonction de callback, il faut spécifier au moins 2 arguments qui sont la requête et la réponse. Je vais les appeler req et res. Bien sûr, vous pouvez les renommer comme vous souhaitez, mais il est conventionnel d'utiliser ces noms-là. Donc Dans ce cas, l'objet req fait référence à la requête passée et l'objet res, c'est la réponse que l'on doit envoyer au client. Une chose importante à savoir, c'est que le framework Express est axé sur les middleware, c'est-à-dire que toutes les fonctions que nous allons créer dans notre code sont en fait des middleware. Un middleware est une fonction qui a accès à l'objet req et à l'objet res et il peut par conséquent leur apporter des modifications. Dans ce cas, le deuxième argument que nous avons spécifié qui est une fonction de callback n'est rien d'autre qu'un middleware qui a accès à l'objet req et l'objet res. Imaginez qu'on veut envoyer une réponse au client dans ce cas. Alors on va invoquer l'objet Réponse, res, et on lui associe la méthode send. On affiche le message voulu, par exemple GET. Maintenant quand j'exécuterai la requête, j'aurai le message sur le navigateur et non pas sur la console. Comme ceci. Et désormais le navigateur ne mouline plus parce qu'on a mis fin au processus requête-réponse. Il est possible de mettre fin au processus grâce à la méthode end. Par exemple res.end. Mais inutile de faire ça parce que déjà send fait ce travail automatiquement. Maintenant je vais spécifier une autre route. Il suffit de copier ce bout de code. Je vais le coller ici. Je mettrai par exemple contact. C'est-à-dire si l'utilisateur souhaite accéder à cette ressource à travers la méthode GET, exécutera cette fonction. Cette fois-ci on va changer de message et je mettrai le message contact. Exécutons. Alors sur la racine j'ai le message GET et si je change de chemin j'ai le message contact. On a maintenant déclaré 2 routes mais on a toujours utilisé la même méthode GET. On peut changer de méthode par exemple pour la deuxième route. À la place de GET, on mettra POST. Mais pour faire le test, j'ai besoin d'une application frontend, chose que je n'ai pas encore pour le moment. Alors on va utiliser un simulateur de frontend qui s'appelle Postman. C'est un logiciel gratuit que vous pouvez télécharger et utiliser. Il sert en fait de faire des tests sur des API. Sur la barre d'adresse, on va spécifier l'URL. Sans oublier le port et on met le chemin contact. Ça me donne une erreur cannot get et c'est normal parce que je n'ai pas utilisé la bonne méthode. La bonne méthode c'est POST et là ça me donne contact. À la place de POST je peux mettre PUT. Je change de méthode et je conserve l'URL et j'ai toujours le message qui s'affiche. On peut aussi tester DELETE et ça marche très bien. En général, ce sont ces 4 méthodes qui sont utilisées pour créer une API, à savoir GET, POST, PUT et DELETE. Maintenant on va remettre la méthode GET et on va essayer de mettre le même chemin. Dans la première route je mettrai juste une console. Par exemple j'affiche requête 1 et sur la deuxième je mettrai requête 2. Alors dans ce cas je suis censé avoir la réponse sur la console et non pas sur le navigateur. Alors exécutons. Je fais le test sur navigateur cette fois parce que je n'ai que la méthode GET. Je spécifie la racine. Alors on constate que le message qui est affiché à la console est celui de la route 1, c'est-à-dire requête 1. En fait c'est normal, c'est-à-dire que Express va comparer la requête avec chacune des routes dans leur ordre de déclaration. S'il trouve une correspondance, alors il s'arrête à la première route valable, ce qui est dans ce cas la première. Et si jamais je veux exécuter les deux routes puisqu'ils correspondent au même chemin et à la même méthode, dans ce cas je vais ajouter sur la première route un autre argument qui s'appelle next. Next va implémenter une fonction qui va donner accès aux prochaines routes qui correspondent au même chemin. Dans ce cas je vais la spécifier à la fin de l'exécution comme ça. C'est-à-dire que désormais Express va exécuter la première route, ensuite il va exécuter next pour chercher une autre route correspondante qui est dans ce cas la deuxième. Alors exécutons. Maintenant j'ai 2 messages: requête 1 et requête 2. Et pareil si jamais j'ai une troisième route, dans ce cas il suffit de spécifier next ici que j'appellerai ensuite à la fin de l'exécution et ainsi de suite. Alors effaçons ce code pour simplifier. Je vais remettre la première version. Maintenant je vais créer une fonction que j'appellerai mid pour dire middleware qui contient les 2 arguments req et res et dedans je mettrai console.log middleware. Alors vous avez constaté que je n'ai associé ce middleware à aucune route mais quand est-ce qu'elle sera exécutée? C'est à nous de décider. Alors imaginez que je veux que ce middleware s'exécute dans la première route. Dans ce cas je peux intercaler le nom de la fonction ici en guise de deuxième arguments, c'est-à-dire que désormais dans la méthode GET on a spécifié 3 arguments à savoir l'URL ou bien le chemin, la fonction de middleware que je viens de créer et la fonction middleware propre à la route. Alors exécutons. On constate que le message affiché c'est middleware, c'est-à-dire celui que nous avons déclaré avant alors que requête1 ne s'affiche pas et c'est pour la même raison parce qu'il faut spécifier next ici. Réexécutons. Maintenant on constate que les 2 messages sont affichés. Alors n'oubliez pas next et ça son rôle, il va juste donner la main au prochain middleware de s'exécuter au cas où la route correspond. Mais imaginez cette fois que je veux que ce middleware s'exécute quelle que soit la route, c'est-à-dire pas forcément GET avec la racine mais peu importe l'URL passée et peu importe la méthode utilisée. Dans ce cas, je vais retirer cet argument et je vais faire appel à la méthode use de l'instance App comme ceci. Et dedans, je vais spécifier le nom de la fonction mid. C'est-à-dire que quelle que soit la requête passée par le client, ce middleware va s'exécuter dans tous les cas. Alors exécutons. Donc on a bien le middleware qui est exécuté. Maintenant on va changer de chemin, on mettra par exemple /about. Dans ce cas ça donne Cannot GET parce qu'on n'a pas spécifié de route relative à ce chemin et pourtant nous avons middleware qui est affiché. C'est-à-dire que cette fonction s'exécute dans tous les cas quelle que soit la route et quelle que soit la méthode. Alors j'espère que vous avez maintenant compris comment passer nos premières requêtes et comment récupérer la réponse sur le client et le plus important c'est que vous ayez compris le principe de routes et de middleware. Merci pour votre attention et à la vidéo prochaine.
