HTTP et cycle de requête

Comprendre le mécanisme

HttpFoundation représente requêtes et réponses ; HttpKernel orchestre leur traitement. Le routage identifie un contrôleur, les résolveurs préparent ses arguments puis le contrôleur produit une réponse. Des événements du kernel permettent d’intervenir à des étapes précises, notamment pour traiter une exception ou ajuster une réponse. Un subscriber déclare les événements qu’il écoute ; les priorités ordonnent des traitements, sans remplacer un contrat fonctionnel explicite.

Raisonner et vérifier

Distinguez le protocole HTTP de l’état métier. Un GET doit conserver la sémantique de lecture attendue ; une erreur de validation n’est pas une erreur interne. Une redirection renvoie au client une autre destination, tandis qu’une sous-requête interne reste un mécanisme serveur. Pensez également à la négociation de contenu, aux cookies et au cache lorsqu’une même URL peut avoir plusieurs représentations.

Du message HTTP aux objets du framework

HttpFoundation fournit notamment les objets Request et Response. HttpKernel organise leur cycle de traitement pour transformer une demande en réponse selon les composants configurés. Les deux responsabilités sont distinctes : disposer d’un objet Request ne valide pas encore son contenu et disposer d’un contrôleur ne décrit pas tous les événements qui peuvent intervenir autour de lui.

Lire la chronologie des événements

Un listener peut intervenir avant la résolution ou l’exécution du contrôleur selon l’événement auquel il participe. L’ordre et les priorités deviennent donc une partie du comportement réel. Pour diagnostiquer un refus, notez l’étape atteinte et les effets observés. Ajouter un log uniquement dans l’action ne permet pas de conclure qu’aucune demande n’a traversé les couches précédentes.

Une réponse anticipée termine un chemin différent

Lorsqu’un traitement amont fournit une Response selon le cycle du kernel, le contrôleur peut ne pas être appelé. Cette possibilité sert à des refus ou réponses précoces, mais exige de placer les contrôles au bon endroit. Un test doit vérifier le statut et l’absence des effets de l’action évitée ; constater un message d’erreur ne prouve pas à lui seul cette chronologie.

Transformer une exception sans exposer la cause

Le traitement d’erreur peut produire une réponse adaptée à partir d’une exception. La représentation publique doit rester contrôlée et utile, tandis qu’un diagnostic privé peut conserver la cause avec une corrélation. Ne convertissez pas toute erreur en succès nominal. Vérifiez aussi les erreurs inattendues : leur chemin de rendu ne doit pas devenir une fuite de trace, de chemins ou de credentials.

Distinguer requête principale et sous-requête

Une sous-requête interne n’a pas nécessairement le même rôle qu’une nouvelle demande réseau principale. Un listener qui applique aveuglément une action à chaque événement peut donc répéter un traitement ou utiliser un mauvais contexte. Examinez les capacités du cycle ciblé et les cas auxquels le listener doit participer. Une redirection HTTP, au contraire, conduit normalement le client à effectuer une nouvelle requête vers sa destination.

État de requête et services réutilisés

Un service peut vivre au-delà d’une seule opération logique, notamment selon le mode d’exécution et les workers. Conserver l’utilisateur courant dans un champ mutable partagé peut contaminer un autre parcours. Passez le contexte utile explicitement ou utilisez les abstractions prévues avec un cycle maîtrisé. Le test doit exercer deux contextes successifs plutôt que seulement un appel avec une identité favorable.

Valider les données de Request

L’objet Request organise des entrées de transport : paramètres, corps et métadonnées restent à interpréter selon leur provenance. Le framework ne rend pas tout champ authentique parce qu’il est accessible via une API pratique. Définissez format, bornes et autorité de chaque valeur avant son usage métier. La résolution d’un objet ou d’un identifiant ne donne pas automatiquement le droit de le consulter.

Construire une réponse contractuelle

Response porte un statut, des champs et un contenu. Leur combinaison doit représenter le résultat du parcours. Une demande acceptée pour un traitement encore asynchrone peut relever de 202 lorsque le contrat explique cette attente. Un contenu JSON contenant true ne prouve pas la fin de tous les effets. Les tests doivent examiner ce que le client peut déduire du message entier.

Le cache peut modifier le chemin observé

Une réponse réutilisée par un cache peut éviter une partie du traitement d’origine. Le contrôleur n’est donc pas nécessairement réexécuté à chaque consultation visible par le navigateur. Pour des données personnalisées, définissez clé, portée et invalidation selon les identités pertinentes. Une capture nominale ne démontre pas que le même contenu ne sera jamais partagé avec un autre acteur.

Prouver l’ordre et le non-effet

Pour un refus avant mutation, vérifiez simultanément la réponse et les données ou appels aval qui doivent rester intacts. Cette preuve relie un mécanisme du kernel à son objectif réel. Préparez un cas autorisé pour éviter de tester seulement un système qui refuse tout. Conservez la version et le chemin d’exécution pertinent afin qu’un autre développeur puisse reproduire la décision.

Atelier guidé : lire, expliquer et vérifier le code

<?php
declare(strict_types=1);
use Symfony\Component\HttpKernel\Event\RequestEvent;
use Symfony\Component\HttpFoundation\Response;
function rejectEarly(RequestEvent $event): void {
    $event->setResponse(new Response('Unavailable', 503));
}

Le listener de l’atelier reçoit un RequestEvent et lui associe une Response 503. Dans le contexte indiqué avant la résolution du contrôleur, cette réponse peut être utilisée comme résultat anticipé. Elle ne supprime pas des lignes de base et ne change pas automatiquement le statut en 200. La propriété importante est le chemin du cycle qui s’arrête avant l’action prévue.

Dans un test de laboratoire, donnez au contrôleur un collaborateur qui enregistrerait une écriture, puis vérifiez que ce collaborateur n’est pas appelé lorsque le refus anticipé s’applique. Ajoutez ensuite un cas nominal sans refus. Vous obtenez une preuve discriminante du cycle plutôt qu’une simple assertion sur un corps de réponse identique dans toutes les situations.