Comprenez le protocole HTTP dans Symfony

Découvrez votre application

Maintenant que nous avons un projet prêt à être utilisé, il est temps de commencer à construire l’application de votre client. Ça tombe bien, Sébastien vous a envoyé des wireframes créés par le graphiste de votre entreprise pour la page d’accueil. Amélie souhaite que celle-ci soit en ligne au plus vite afin d’informer le public de l’ouverture prochaine de l’application.

Commencez par ouvrir un éditeur de code dans le dossier  biblios  qui vient d’être créé. Voici la structure que vous devriez trouver :

biblios/
├── assets
│   ├── …
├── bin
│   ├── console
│   └── …
├── config
│   ├── packages
│   ├── …
│   ├── routes.yaml
│   └── services.yaml
├── migrations
├── public
│   └── index.php
├── src
│   ├── Controller
│   ├── Entity
│   ├── Repository
│   └── Kernel.php
├── templates
│   └── base.html.twig
├── tests
├── translations
├── var
│   ├── cache
│   └── log
├── vendor
│   ├── bin
│   ├── composer
│   ├── …
├── composer.json
├── composer.lock
├── …
└── symfony.lock

Vous n’avez pas à vous soucier de tout ce que vous voyez. Au début, vous passerez l’essentiel de votre temps dans trois dossiers :

• config  , qui contient tous les fichiers de configuration de votre application ;

• src  , le dossier source dans lequel vous écrirez votre code PHP ;

• templates  , où nous mettrons les pages HTML de notre site. 

Ensuite, ouvrez un terminal et lancez la commande suivante :

symfony serve -d

Cette commande lance le serveur interne de test de PHP, ce qui vous permet de consulter votre toute nouvelle application. Pour cela, ouvrez votre navigateur préféré et entrez l’adresse qui vous a été retournée par la commande (normalement,  https://127.0.0.1:8000  ).

Cette page qui s’affiche est la page d’accueil de Symfony pour toutes les applications qui viennent d’être créées. Elle ne s’affiche que lorsque vous êtes en phase de développement et que vous n’avez pas encore créé de page d’accueil bien à vous. Tant que vous n’aurez pas configuré de page correspondant aux souhaits d’Amélie, vous verrez cette page.

Sébastien, qui vous chaperonne, attire votre attention sur une autre chose intéressante qui apparaît sur cette page. Regardez en bas.

Tu vois cette barre noire ? C’est la barre du Profiler de Symfony, la toolbar. C’est ton meilleur ami pour le debug ! Clique sur une des icônes qu’il y a dessus, tu vas voir. 

Ce profiler vous affiche tout un tas d’informations au sujet de la page que vous êtes en train de visiter. À commencer par le petit code numérique sur une pastille rouge en bas à gauche : le code HTTP de la réponse renvoyée par votre application.

Revenez sur le protocole HTTP

Il est temps de faire un rapide retour sur ce que cela signifie. Étant donné que répondre à des requêtes HTTP est le rôle principal de notre future application, il est important de savoir de quoi on parle.

Le protocole HTTP fonctionne simplement par un échange de messages entre deux parties : le Client et le Serveur.

D’un côté, le Client envoie un premier message, la Requête, et de l’autre le serveur renvoie une Réponse. Les deux ont la même structure – une première ligne descriptive, une série d’en-têtes sous forme de paires clé-valeur, une ligne vide, puis un corps de message – mais un contenu différent.

Pas de panique, vous n’avez pas besoin de connaître par cœur tous les en-têtes possibles ou ce genre de détail. Connaître le fonctionnement simplifié tel que nous venons de l’expliquer ainsi que les quelques informations qui viennent suffira.

La requête

Tout d’abord, regardez la première ligne de la requête. Dans l’ordre, les trois éléments que nous avons sont : une méthode HTTP (ou verbe HTTP, “GET”), une ressource (le chemin auquel on tente d’accéder, “/request”), et la version du protocole HTTP qui a été utilisée (ici “HTTP/2”). Les deux premiers éléments vont nous être utiles très rapidement dans les prochains chapitres.

Premièrement, la méthode HTTP. Il y en a plusieurs possibles, chacune ayant une signification spécifique. Elles permettent au client d’indiquer au serveur le type d’action qu’il souhaite effectuer. Ici, “GET” indique que la requête a pour but de récupérer des informations. Ici encore, pas besoin de les connaître toutes, les suivantes suffiront :

Pour ce qui est de la ressource, il s’agit d’une adresse relative à celle de votre site. C’est-à-dire que si quelqu’un tape https://www.votresite.com/une-certaine-page dans son navigateur, la ressource sera/une-certaine-page  .

La réponse

La réponse a la même structure que la requête, mais le contenu est différent. Cette fois, nous avons la version du protocole HTTP utilisée en premier. Ensuite, viennent deux informations primordiales : un code de réponse, suivi de sa version textuelle. Ce code nous offre une information instantanée sur l’état de notre réponse.

Pas du tout : il en existe un grand nombre. Vous connaîtrez la plupart au fil du temps, mais pour commencer, il suffit de connaître les principaux et de savoir qu’ils sont répartis en catégories :

Parmi les codes les plus fréquents, on peut noter le  200 OK  , le fameux  404 Not Found  , ou encore l’erreur  500 Internal Server Error  .

Outre ces codes, la réponse contient aussi un contenu, sa troisième partie. C'est-à-dire que si vous avez demandé une page web, le code HTML de cette page se trouve dans ce corps de réponse.

Comprenez la requête dans Symfony

Tout ! Comme nous l’avons dit plus haut, Symfony est un framework HTTP. Son but est de vous permettre de recevoir des requêtes et de renvoyer les réponses adéquates. Puisque Symfony doit traiter des requêtes, elles doivent donc avoir une représentation dans Symfony : il s’agit de l’objet  Request  , tout simplement. Cet objet se trouve dans le composant  HttpFoundation  , une des briques de base de Symfony. L’objet  Request  est unique dans votre application. Il représente donc la requête qui a déclenché le lancement de l’application, et toutes les informations qui vont avec. 

Vous y trouverez en particulier les méthodes et propriétés suivantes :

<?php
// les trois propriétés suivantes sont des objets qui contiennent tous une méthode all() qui renvoie tout leur contenu et une méthode get($key) pour récupérer une valeur
$request->query; // données envoyées dans l’URL, contenu de $_GET
$request->query->get(‘param’); // renverra la valeur “foo” passée dans le paramètre d’URL “param”, par exemple avec “www.monsite.com/une-route?param=foo”
$request->request; // données envoyées dans $_POST
$request->attributes; // données ajoutées par Symfony
$request->getMethod(); // renvoie la méthode HTTP de la requête
$request->getPathInfo(); // renvoie la ressource demandée
$request->getContent(); // renvoie le contenu brut de la requête

Suivez la requête dans Symfony

Nous avons reçu une requête, et nous avons désormais un objet pour la représenter dans notre application. Notre application va donc pouvoir traiter cette requête et renvoyer une réponse. Voici schématiquement ce qu’il va se passer :

Chaque chose en son temps ! Nous allons détailler tout cela un minimum au fil des chapitres qui viennent, mais pour l’instant voici déjà une première explication :

• Tout d’abord, le front controller est tout simplement le fichier qui sert de point d’entrée à notre application. Toutes les requêtes qui arrivent transitent par lui, et c’est lui qui est chargé de démarrer…

• Le Kernel de Symfony, c’est le centre de notre application. C’est lui qui sera chargé de gérer la configuration de l’application, prendre en charge la requête, et récupérer la réponse adéquate.

• Vous ne coderez ou ne toucherez cependant pas à tout dans cette liste, l’essentiel de votre travail se cantonnera aux controllers.

• Pour savoir comment répondre de la bonne façon à une requête, il faut savoir quelle est la demande. Et cela sera fait grâce au Routing. Voyez-le comme le policier qui fait la circulation. Nous allons permettre à notre application de gérer plusieurs routes possibles, et le routing fera l’aiguillage.

• Les controllers sont la dernière pièce du puzzle. Ce sont eux qui seront chargés de renvoyer une réponse, le plus souvent sous la forme d’un objet de la classe Response.

En résumé

• Dans le protocole HTTP, un Client envoie une Requête à un Serveur, qui lui renvoie une Réponse.

• Une requête se définit entre autres par une méthode et une ressource.

• Une réponse se définit entre autres par un code et un contenu.

• Le but de Symfony est de nous aider à traiter des requêtes et renvoyer ces réponses.

• Le Kernel de Symfony gère la configuration de notre application et exécute le traitement de la requête.

Et maintenant, voyons dans le prochain chapitre comment les routes et les controllers vont nous permettre de répondre aux requêtes entrantes !