Créez et testez une première route avec NestJS

Dans le chapitre précédent, vous avez découvert l'architecture de NestJS et identifié les rôles du Module, du Controller et du Service. Il est maintenant temps de voir comment ces trois éléments interagissent en direct lorsqu'on utilise votre application. Voyons ensemble comment une simple requête se transforme en données concrètes.

Suivez le chemin d'une requête HTTP

Imaginons qu'un utilisateur ouvre votre application de gestion de tâches. Son navigateur (le client) envoie une requête HTTP à votre serveur. Voici le chemin exact que va emprunter cette requête à l'intérieur de NestJS.

Tout commence dans le fichiermain.ts. Ce fichier réceptionne la demande et la transmet au routeur interne du framework. Le routeur analyse l'URL demandée et dirige la requête vers le bon Controller.

Ici, le Controller agit comme un chef de gare. Il regarde le billet du passager (la requête), comprend sa destination, et l'oriente vers le bon quai. Mais attention, le chef de gare ne conduit pas le train lui-même ! C'est le rôle du Service.

Schéma illustrant le flux : requête client vers contrôleur, traitement par service, interaction avec la base de données, puis retour d’une réponse validée à l’utilisateur.
Une requête est traitée par un controller puis un service avant de produire une réponse

Le Controller délègue donc la tâche au Service. Le Service, qui ne sait d'ailleurs pas qu'il parle à travers le protocole HTTP, exécute le véritable travail : il va chercher les données dans la base, fait ses calculs, et retourne le résultat brut au Controller. Enfin, le Controller emballe ce résultat dans une réponse HTTP valide et la renvoie au client.

Mais pourquoi séparer ces deux rôles si l'on pourrait tout écrire au même endroit pour aller plus vite ?

C'est le principe de séparation des responsabilités. Le fait que le Controller ne gère que les requêtes et que le Service ne gère que la logique métier rend notre code extrêmement clair. Avoir une bonne séparation des responsabilités permet d'avoir une bien meilleure maintenabilité d'une application. De plus, cette séparation rend chaque morceau de code beaucoup plus facile à tester de manière isolée.

Créez votre première route GET

Concrètement, comment cela se traduit-il dans le code ? Voyons ensemble comment exposer la liste de nos projets. Nous allons commencer par l'équipe en coulisses : le Service. Dans votre fichier

app.service.ts, nous ajoutons une méthode que nous appelleronsgetProjects(). Pour le moment, pas de base de données complexe : cette méthode va simplement retourner un tableau statique contenant quelques projets fictifs. 

Ensuite, nous remontons à l'accueil : le Controller. Dans le fichier

app.controller.ts, nous allons lier l'URL/projectsà la méthode de notre Service. Pour cela, nous utilisons le décorateur@Get('projects')juste au-dessus de la méthode du Controller. Ce décorateur indique au routeur : "Si une requête GET arrive sur le chemin /projects, c'est ici qu'il faut l'envoyer".

Dans ce screencast, nous allons construire ensemble une première route simple, en suivant le flux que vous venez de découvrir, du service jusqu’au contrôleur.

Voici à quoi ressemble notre Controller après modification :

import { Controller, Get } from '@nestjs/common';
import { ProjectService } from './app.service';
@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}
  @Get('projects')
  getProjects() {
    return this.appService.getProjects();
  }
}

Vous remarquez que le Controller se contente d'appelerthis.appService.getProjects(). Il ne crée pas la donnée, il délègue. Pour voir le résultat, il ne nous reste plus qu'à lancer le serveur avec la commandenpm run start:dev.

Testez votre route avec un client HTTP

Écrire du code est une chose, vérifier qu'il fonctionne en est une autre. Avant même de penser à écrire des tests unitaires, nous devons valider manuellement que notre route répond correctement.

Puisqu'il s'agit d'une simple requête GET, vous pouvez ouvrir votre navigateur web et taperhttp://localhost:3000/projects. Vous verrez votre liste s'afficher. Cependant, le navigateur n'est pas l'outil idéal pour un développeur back-end.

Je vous recommande vivement d'utiliser un client HTTP dédié, comme Postman ou l'extension Thunder Client directement dans votre éditeur. Ces outils vous permettent de forger des requêtes précises et d'analyser la réponse du serveur dans les moindres détails.

Lorsque vous lancez votre requête GET vers votre URL dans Postman, observez attentivement le résultat. Vous devez vérifier deux choses essentielles :

  1. Le code de statut (status code) : il doit indiquer 200 (OK), ce qui signifie que la requête a été traitée avec succès.

  2. Le corps de la réponse : vous devriez voir vos données s'afficher sous la forme d'un objet JSON propre et bien formaté.

Vérification du statut 200 et du JSON dans Postman
Vérification du statut 200 et du JSON dans Postman

À vous de jouer !

L’architecture de l’application est maintenant documentée grâce à vous. Votre tech lead souhaite passer à une fonctionnalité clé : permettre au front-end de récupérer un projet spécifique.

Votre mission consiste à implémenter une route permettant d’obtenir un projet à partir de son identifiant.

Consignes

À partir du projet NestJS de démarrage fourni dans l’archive ZIP, réalisez les actions suivantes :

  1. Modifiez le Service pour qu’il contienne une liste statique de trois projets fictifs (chaque projet doit avoir unid, untitreet unedescription).

  2. Ajoutez une méthode permettant de récupérer un projet en fonction de sonid.

  3. Exposez cette méthode dans le Controller via une requête GET sur le chemin/projects/:id.

  4. Testez votre route dans Postman (ou Thunder Client) avec un identifiant valide. Vérifiez que vous obtenez un code de statut 200 et les données du projet correspondant.

En résumé

  • Une requête HTTP entrante est reçue par le point d'entrée principal avant d'être dirigée vers le bon contrôleur par le routeur de NestJS.

  • Le contrôleur agit comme un point d'accueil qui réceptionne la demande et la délègue au service correspondant sans jamais la traiter lui-même.

  • Le service exécute la logique métier en ignorant le contexte HTTP, garantissant ainsi une parfaite séparation des responsabilités.

  • Le décorateur @Get() permet d'associer facilement une URL spécifique à une méthode précise de votre contrôleur.

  • L'utilisation d'un client HTTP comme Postman ou Thunder Client est indispensable pour vérifier le code de statut et inspecter la réponse JSON renvoyée par le serveur.

Vous êtes maintenant capable de comprendre le cycle de vie d'une requête et de créer une route HTTP basique. Dans le prochain chapitre, nous irons plus loin en apprenant à récupérer et manipuler des données envoyées dynamiquement par nos utilisateurs !

Et si vous obteniez un diplôme OpenClassrooms ?
  • Formations jusqu’à 100 % financées
  • Date de début flexible
  • Projets professionnalisants
  • Mentorat individuel
Trouvez la formation et le financement faits pour vous