Laravel le routage

Dans ce chapitre, nous explorerons le parcours d'une requête HTTP au sein de notre application Laravel. Nous découvrirons l'importance d'utiliser un fichier .htaccess pour simplifier les URL. De plus, nous examinerons le système de routage qui permet de trier et de diriger les requêtes de manière efficace.

Les requêtes HTTP

Petit rappels

On va commencer par un petit rappel sur ce qu’est une requête HTTP. Voici un schéma illustratif :

Le HTTP (Hypertext Transfer Protocol) est un protocole de communication entre un client et un serveur, défini par l'IETF (Internet Engineering Task Force). Il est largement utilisé pour l'échange de ressources sur le World Wide Web. Dans ce modèle de communication client-serveur, le client envoie une requête pour demander une ressource au serveur, qui répond en retour en envoyant une réponse, généralement sous la forme d'une page HTML.

Lorsque vous naviguez sur Internet, chaque clic génère habituellement un tel échange entre votre navigateur (le client) et le serveur web. En réalité, une seule page web peut déclencher plusieurs de ces échanges, car une page peut être composée de diverses ressources, telles que des images, des fichiers CSS ou JavaScript, etc.

Une requête HTTP contient diverses informations, notamment les en-têtes (headers), le code d'état (status code), et le corps de la requête (body). Les en-têtes fournissent au serveur des informations sur la requête, comme la langue préférée du client, le type de navigateur utilisé, ou encore la méthode de la requête (GET, POST, PUT, DELETE, etc.). Le code d'état indique le résultat de la requête, par exemple 200 OK pour une requête réussie, 404 Not Found pour une ressource non trouvée, ou 500 Internal Server Error pour une erreur interne au serveur. Enfin, le corps de la requête peut contenir des données envoyées au serveur, comme les informations saisies dans un formulaire web.

La réponse HTTP comporte également des en-têtes, un code d'état, et un corps. Les en-têtes de la réponse peuvent fournir des informations sur le contenu de la réponse, comme son type (HTML, JSON, XML, etc.) ou son encodage (UTF-8, ISO 8859-1, etc.). Le corps de la réponse contient généralement la ressource demandée, telle qu'une page HTML, une image, ou des données JSON.

HTTP est un protocole sans état, ce qui signifie que chaque requête et chaque réponse est traitée indépendamment des précédentes. Pour maintenir un état entre plusieurs échanges, des mécanismes tels que les cookies ou les tokens de session sont utilisés.

Prenons l'exemple de ce blog. Lorsque je clique sur un lien, voilà un aperçu de toutes les requêtes HTTP qui se produisent :

Regardons d’un peu plus près l'une d'elles :

On trouve :

l’url : https://laravel.sillo.org/posts/shop-les-frais-de-port
la méthode : GET
le code : 200 (donc tout s’est bien passé)
la version du HTTP : 2

Il y a évidemment bien d’autres choses dans les headers (content-type, cookies, encodage…) mais pour le moment, on va se contenter de ces informations. Notre navigateur digère tout ça de façon transparente, heureusement pour nous !

Notre application Laravel doit savoir interpréter les informations qui arrivent et les utiliser de manière pertinente pour renvoyer ce que demande le client. Nous allons voir comment cela est réalisé.

Les méthodes

Il est essentiel de connaître les principales méthodes HTTP :

GET : c'est la méthode la plus courante. Elle permet de demander une ressource sans la modifier. Les requêtes GET peuvent être mémorisées (cachées) par le navigateur, garantissant ainsi que la même ressource sera toujours obtenue.
POST : très couramment utilisée, cette méthode permet d'envoyer des données au serveur pour créer ou modifier une ressource. Un cas classique est la soumission d'un formulaire. Bien que souvent utilisée à tort à la place de PUT, POST est idéale pour des opérations non idempotentes.
PUT : cette méthode permet d'ajouter ou de remplacer complètement une ressource existante. Elle est idempotente, ce qui signifie que plusieurs requêtes PUT identiques auront le même effet qu'une seule requête.
PATCH : contrairement à PUT, cette méthode permet de modifier partiellement une ressource. Elle est utilisée pour appliquer des modifications spécifiques sans remplacer l'ensemble de la ressource.
DELETE : cette méthode permet de supprimer une ressource sur le serveur. Elle est également idempotente, ce qui signifie que plusieurs requêtes DELETE identiques auront le même effet qu'une seule requête.

Différence entre PUT et POST

PUT et POST sont deux méthodes HTTP couramment utilisées pour créer ou mettre à jour des ressources sur un serveur. Bien qu'elles partagent certaines similitudes, elles possèdent des caractéristiques distinctes qui les différencient.

PUT :

Utilisation : la méthode PUT est utilisée pour mettre à jour une ressource existante ou pour créer une ressource spécifique si elle n'existe pas déjà.
URI : lors de l'utilisation de PUT, l'URI (Uniform Resource Identifier) doit contenir l'identifiant de la ressource à mettre à jour ou à créer.
Idempotence : les requêtes PUT sont idempotentes, ce qui signifie que l'envoi de la même requête PUT plusieurs fois aura le même effet que si elle avait été envoyée une seule fois. Cela est crucial pour éviter de créer ou de mettre à jour une ressource plusieurs fois en cas de problèmes de réseau.

POST :

Utilisation : la méthode POST est principalement utilisée pour créer une nouvelle ressource, mais elle peut également être utilisée pour mettre à jour des ressources existantes, bien que PUT soit plus couramment utilisé pour cette dernière opération.
URI : lors de l'utilisation de POST, l'URI ne contient pas l'identifiant de la ressource à créer, car cet identifiant est généralement assigné par le serveur une fois la ressource créée.
Idempotence : les requêtes POST ne sont pas idempotentes, ce qui signifie que l'envoi de la même requête POST plusieurs fois peut avoir un effet différent à chaque fois.

En résumé :

PUT est plus spécifique et doit être utilisé lorsque vous travaillez avec des ressources identifiées par une URI. Il est idempotent.
POST est plus général et adapté à la création de ressources où l'URI n'est pas connue à l'avance. Il n'est pas idempotent.

.htaccess et index.php

Pour Laravel on veut que toutes les requêtes aboutissent obligatoirement sur le fichier index.php situé dans le dossier public. Pour y arriver, on peut utiliser une URL de ce genre :

http://monsite.fr/index.php/mapage

Mais ce n’est pas très esthétique avec ce index.php au milieu. Si vous avez un serveur Apache, lorsque la requête du client arrive sur le serveur où se trouve notre application Laravel, elle passe en premier par le fichier .htaccess, s’il existe, qui fixe des règles pour le serveur. Il y a justement un fichier .htaccess dans le dossier public de Laravel avec une règle de réécriture de telle sorte qu’on peut avoir une url simplifiée :

http://monsite.fr/mapage

Un petit schéma pour visualiser cette action :

Pour que ça fonctionne, il faut que le serveur Apache ait le module mod_rewrite activé.

Nous avons vu le fichier .htaccess de Laravel dans le précédent article, avec des commentaires.

Le cycle de la requête

Lorsque la requête atteint le fichier public/index.php l’application Laravel est créée et configurée et l’environnement est détecté. Nous reviendrons plus tard en détail sur ces étapes (kernel, providers, middlewares, session...). Ensuite, le fichier routes/web.php est chargé. Voici l’emplacement de ce fichier :

Les autres fichiers concernent des routes plus spécifiques comme les actions en ligne de commande avec le fichier console.php.

C’est avec ce fichier que la requête va être analysée et dirigée. Regardons ce qu’on y trouve au départ :

use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    return view('welcome');
});

Comme Laravel est explicite, vous pouvez déjà deviner à quoi sert ce code :

Route : on utilise le routeur,
get : on regarde si la requête a la méthode GET,
‘/’ : on regarde si l’url comporte uniquement le nom de domaine,
dans la fonction anonyme, on retourne (return) une vue (view) à partir du fichier « welcome ».

Ce fichier « welcome » se trouve bien rangé dans le dossier des vues :

C’est ce fichier comportant du code Html qui génère le texte d’accueil que vous obtenez au démarrage initial de Laravel :

Laravel propose plusieurs helpers qui simplifient la syntaxe. Il y a par exemple view pour la classe View comme on l’a vu dans le code ci-dessus.

Visualisons le cycle de la requête :

Sur votre serveur local, vous n’avez pas de nom de domaine et vous allez utiliser une url de la forme http://localhost/tuto/public en admettant que vous ayez créé Laravel dans un dossier www/tuto. Mais vous pouvez aussi créer un hôte virtuel pour avoir une situation plus réaliste comme déjà évoqué au précédent chapitre.

Laravel accepte les verbes suivants : get, post, put, patch, delete, options, match (pour prévoir plusieurs verbes) et any (on accepte tous les verbes).

Plusieurs routes et paramètre de route

À l’installation, Laravel a une seule route qui correspond à l’URL de base composée uniquement du nom de domaine. Voyons maintenant comment créer d’autres routes. Imaginons que nous ayons 3 pages qui doivent être affichées avec ces urls :

http://monsite.fr/1
http://monsite.fr/2
http://monsite.fr/3

J’ai fait apparaître en gras la partie spécifique de l’url pour chaque page. Il est facile de réaliser cela avec ce code :

Route::get('1', function() { return 'Je suis la page 1 !'; });
Route::get('2', function() { return 'Je suis la page 2 !'; });
Route::get('3', function() { return 'Je suis la page 3 !'; });

Cette fois, je n’ai pas créé de vue parce que ce qui nous intéresse est seulement une mise en évidence du routage, je retourne donc directement la réponse au client. Visualisons cela pour la page 1 :

On a besoin du caractère « / » seulement dans la route de base.

On peut à présent se poser une question : est-il vraiment indispensable de créer 3 routes alors que la seule différence tient à peu de chose : une valeur qui change ?

On peut utiliser un paramètre pour une route qui accepte des éléments variables en utilisant des accolades. Regardez ce code :

Route::get('{n}', function($n) {
    return 'Je suis la page ' . $n . ' !';
});

Et une visualisation du fonctionnement :

On dit que la route est paramétrée parce qu’elle possède un paramètre qui peut prendre n’importe quelle valeur.

On peut rendre un paramètre optionnel en lui ajoutant un point d’interrogation, mais il ne doit pas être suivi par un paramètre obligatoire. Dans ce cas, pour éviter une erreur d’exécution, il faut prévoir une valeur par défaut pour le paramètre, par exemple :

Route::get('{n?}', function($n = 1) {

Le paramètre n est devenu optionnel et par défaut sa valeur est 1.

Erreur d’exécution et contrainte de route

Dans mon double exemple précédent, lorsque je dis que le résultat est le même, je mens un peu. Que se passe-t-il dans les deux cas pour cette url ?

http://monsite.fr/4

Dans le cas des trois routes, vous tombez sur une erreur :

Par contre dans la version avec le paramètre, vous obtenez une réponse valide ! Ce qui est logique parce qu’une route est trouvée. Le paramètre accepte n’importe quelle valeur et pas seulement des nombres. Par exemple avec cette url :

http://monsite.fr/nimportequoi

Vous obtenez :

Je suis la page nimportequoi !

Ce qui vous l’avouerez n’est pas très heureux !

Pour éviter ce genre de désagrément, il faut contraindre le paramètre à n’accepter que certaines valeurs. On peut réaliser cela à l’aide d’une expression régulière :

Route::get('{n}', function($n) {
    return 'Je suis la page ' . $n . ' !';
})->where('n', '[1-3]');

Maintenant, je peux affirmer que les comportements sont identiques ! Mais il nous faudra régler le problème des routes non prévues.

Route nommée

Il est parfois utile de nommer une route, par exemple pour générer une url ou pour effectuer une redirection. La syntaxe pour nommer une route est celle-ci :

Route::get('/', function() {
  return 'Je suis la page d\'accueil !';
})->name('home');

Par exemple, pour générer l’URL qui correspond à cette route, on peut utiliser l’helper route :

route('home')

Ce qui va générer l’URL de base du site dans ce cas : http://monsite.test.

Un avantage à utiliser des routes nommées est qu’on peut réorganiser les urls d’un site sans avoir à modifier beaucoup de code.

Nous verrons des cas d’utilisation de routes nommées dans les prochains chapitres.

Ordre des routes

Une chose importante à connaître est l’ordre des routes !

Lisez bien ceci pour vous éviter des heures de recherches et de prises de tête. La règle est :

Les routes sont analysées dans leur ordre dans le fichier des routes.

Regardez ces deux routes :

Route::get('{n}', function($n) {
    return 'Je suis la page ' . $n . ' !';
});
 
Route::get('contact', function() {
    return "C'est moi le contact.";
});

Que pensez-vous qu’il va se passer avec http://monsite.test/contact ? Je vous laisse deviner et tester et surtout bien retenir ce fonctionnement ! On peut aussi grouper des routes pour simplifier la syntaxe, mais nous verrons ça plus tard...

En résumé

Laravel possède un fichier .htaccess pour simplifier l’écriture des url.
Le système de routage est simple et explicite.
On peut prévoir des paramètres dans les routes.
On peut contraindre un paramètre à correspondre à une expression régulière.
On peut nommer une route pour faciliter la génération des url ‌et les redirections.

Il y a encore beaucoup à dire sur le routage : le groupement des routes, l'utilisation de middlewares et bien d'autre éléments qui nous verrons progressivement dans ce cours.

La documentation officielle de cette partie est ici.