apprendre

Réserver par pigeon

Exercice 3 sur 6 du chapitre 5 · 240 XP · 5 objectifs vérifiés par des tests

Notions abordées : POST JSONDTO#[MapRequestPayload]201 / 400 / 422

Grande nouvelle : les parchemins peuvent maintenant envoyer des messages. Plus besoin de traverser la forêt pour réserver sa table, un pigeon magique s'en charge. Il apporte un JSON comme celui-ci :

{ "nom": "Gimli", "personnes": 3, "jour": "2026-09-18" }

Votre mission

  1. Complétez le DTO ReservationDemande, qui décrit et valide une demande :
    • nom : obligatoire (« Indiquez votre nom. ») ;
    • personnes : de 1 à 12 (« Le nombre d'aventuriers doit être entre 1 et 12. ») ;
    • jour : obligatoire (« Indiquez le jour de votre venue. »), et pas dans le passé (« On ne réserve pas dans le passé, même avec un parchemin magique. »). Aujourd'hui, c'est permis.
  2. Dans POST /api/reservations, recevez la demande avec #[MapRequestPayload], enregistrez une Reservation, puis répondez 201 Created avec la réservation (groupe reservation).

Essayez les trois requêtes toutes faites de l'onglet Requêtes.

Ce que fait #[MapRequestPayload]

Symfony lit le corps JSON, remplit le DTO, puis le valide. Votre contrôleur ne reçoit que des demandes correctes. Sinon, Symfony répond à votre place :

Problème Réponse
JSON illisible 400 Bad Request
Règle non respectée, champ manquant, mauvais type ("personnes": "trois") 422 Unprocessable Content, avec la liste des violations

Pourquoi un DTO, et pas l'entité ?

La demande n'est pas la réservation. Le DTO ne contient que ce que le client a le droit d'envoyer : impossible de glisser un id ou une date de création. Et la validation de l'API ne dépend pas de la base.