Aller au contenu principal

35-3 Contrôleur IssuesController et route imbriquée

Fin d'obtenir une liste d'issues, en utilisant Supabase, il aurait été possible d'effectuer une requête GET vers /issues, tout en passant un paramètre params pour préciser le projet. Par exemple projet_id: eq.3.

C'est ce qui nous permettait de filtrer les résultats avec Supabase, et surtout, de préciser pour quel projet obtenir les issues. Cependant, il y a une façon un peu plus évidente de passer cette information maintenant que nous contrôlons notre API.

En effet, et si on faisait plutôt une requête à GET /projets/:projetId/issues? L'URL communiquerait ainsi l'identifiant du projet.

Au fond, toutes les routes du contrôleur d’issues seront associées à un projet. Par exemple:

  • GET /projets/:projetId/issues
  • POST /projets/:projetId/issues
  • GET /projets/:projetId/issues/:id
  • PATCH /projets/:projetId/issues/:id
  • DELETE /projets/:projetId/issues/:id

Toutes les routes contiennent projetId. Il est possible de définir au niveau de la route principale du contrôleur que la route de base est projets/:projetId/issues.

C'est ce qu'on appelle une route imbriquée.

Modification de la route de base du contrôleur​

La route de base peut définir un paramètre de cette façon:

@Controller('projets/:projetId/issues')
export class IssuesController {

  //...

Cela aura comme impact de créer les routes suivantes:

Imgur