Différents moyens d’écrire des routes Ruby on Rails

La réécriture d’URL par le serveur web n’est pas possible en Ruby on Rails puisque le serveur applicatif se base sur le format de l’URL pour extraire le contrôleur, la méthode à déclencher et les éventuels paramètres.

La suite de cet article observe les différentes solutions issues de la documentation officielle concernant le routage.

NB : en développement, les routes sont visibles sur http://localhost:3000/rails/info/routes

Les bases de l’option RESTful

Par défaut, les routes Rails utilisent un format décrivant le type de ressource suivi d’une action et d’un éventuel identifiant. Les verbes HTTP permettent de distinguer les comportements concernant une ressource précise :
– créer (GET/POST)
– afficher via l’ID (GET)
– modifier via l’ID (GET/PATCH)
– supprimer via l’ID (DELETE)
– lister (GET)

/membres/1 affiche le membre ayant l’ID 1 en base de données.

Une variante existe où une seule ressource est accessible à la fois, permettant d’afficher, modifier et supprimer sans passer l’ID :

/profil affiche le profil de la personne connectée par une session.

On peut placer les contrôleurs dans des namespaces :

/admin/articles/ liste les articles.

On peut cacher le namespace dans l’URL via :

/articles/ liste les articles.

Ou à l’inverse regrouper des routes sans namespace sous un même préfix :

/admin/articles/ liste les articles.

On peut imbriquer des ressources :

/magazines/1/ads/1 affiche la première publicité du premier magazine.

S’il est possible d’imbriquer autant de niveaux que souhaité, la doc préconise de ne pas aller au delà d’une imbrication.

C’est un format standardisé, pratique mais peu esthétique. Le référencement demande de placer le titre d’un article dans l’URL plutôt que son identifiant numérique. On fait alors appel à des réécritures d’URL.

Les bases de l’option personnalisée

On quitte à présent les bonnes pratiques pour répondre à des besoins spécifiques.

Il existe deux symboles spéciaux pour créer des routes au format de notre choix, qu’on peut associer avec n’importe quel(s) autre(s) symbole(s) de notre choix :

/photos/show/1 permet d’accéder au contrôleur photos, action show, la dernière valeur sera récupérable via un paramètre « id » quelconque. Les parenthèses indiquent les paramètres optionnels. Les slashs sont les séparateurs et peuvent contenir du texte statique.

La route peut être écrite dans n’importe quelle combinaison de symboles et de textes tant qu’aucune autre route n’a été reconnue lors de l’exécution de la requête.

On peut renommer une route RESTful ainsi que sa méthode d’appel :

/exit appellera la méthode destroy du contrôleur sessions, dont le lien sera logout_path.

Cette dernière méthode offre la possibilité de renommer le paramètre d’une action RESTful via un symbole :

/Julien appellera le show du contrôleur users en passant le paramètre username.

match permet d’intercepter un ou plusieurs verbes HTTP vers la même méthode. La documentation averti des risques de sécurité de router le GET et POST vers la même méthode, car Rails ne vérifiera pas le token CSRF en GET.

Limitations et redirections

Il existe ensuite la possibilité d’utiliser des expressions régulières avec l’option constraints, qui peut aussi limiter une route à un sous domaine :

Ou à une protection par IP :

La protection par IP est ici placée dans une méthode de classe du modèle Blacklist retournant un tableau des IP autorisées.

Avec l’option constraint, on peut également forcer une route à retourner un format précis :

/foo n’acceptera que des requêtes dont le header indique le type json.

Les redirections 301 sont simples :

Les 302 aussi :

Il existe de nombreuses autres combinaisons pour gérer les paramètres, décrites dans la documentation, que j’ai volontairement omis dans cet article.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.