#[MapRequestPayload] dans Symfony : un DTO pour le JSON

L'attribut #[MapRequestPayload] remplit un DTO avec le corps JSON de la requête et le valide : le contrôleur Symfony ne reçoit que des données correctes.

final class ReservationDemande
{
    #[Assert\NotBlank(message: 'Indiquez votre nom.')]
    public ?string $nom = null;

    #[Assert\NotNull(message: 'Indiquez le nombre de convives.')]
    #[Assert\Range(min: 1, max: 12)]
    public ?int $personnes = null;
}

#[Route('/api/reservations', methods: ['POST'])]
public function reserver(#[MapRequestPayload] ReservationDemande $demande): JsonResponse
{
    // Ici, la demande est lue et validée ; sinon, Symfony a déjà répondu 400 ou 422.
}

Sans lui, un contrôleur d'API décode le JSON, vérifie chaque champ, convertit les types et fabrique ses réponses d'erreur. Avec l'attribut sur un argument typé, Symfony désérialise, valide, et répond à la place du contrôleur : 400 pour un JSON illisible, 422 avec la liste des violations quand une règle n'est pas respectée. Le piège classique est de mapper directement une entité : le client peut alors envoyer des champs qu'il ne devrait pas toucher. Un DTO ne contient que ce qu'il a le droit d'envoyer, et sa validation ne dépend pas de la base.

Les exercices font recevoir des réservations envoyées par pigeon magique, avec leur DTO et leurs messages d'erreur, puis bâtir l'API qui permet aux guildes d'inscrire leurs membres aux soirées de la taverne, avec les bons codes HTTP pour chaque refus.