URL Rewriting, Friendly URL

A quoi doivent ressembler des URL/URI ? Comment avoir des URL porteuses de sens ? Pour qui ? Pourquoi ? Sans chercher ni à imposer ma conception d'URL ni à réaliser un tutoriel, voici la démarche appliquée aux pages de ce site...

En surfant sur internet, on peut découvrir des URL réécrites de manières suivantes :

http://www.domain.com/path/index.php/act/search/code/perform_serach/key1/url/key2/friendly
http://www.domain.com/blog/index.php/2005/01/03/16h/14m/32s/2-titre-du-sujet
http://www.domain.com/forum-5-sujet-15-page-29-paragraphe-10.html

Il y a un petit quelque chose que je trouve profondément inamical dans ce genre d'adresses. Tant qu'à réécrire des URL, ça vaut peut-être la peine de les réécrire proprement, non ?

Dotclear propose 2 formats d'URL. La différence entre ces formats est visuellement subtile.

http://www.atelierphp5.com/index.php?2005/01/19/8-url-rewriting-friendly-url
http://www.atelierphp5.com/index.php/2005/01/19/8-url-rewriting-friendly-url

Personnellement, je trouve ces adresses URL trop longues et trop compliquées. Toutes les deux.

Un premier pas vers la simplification des URL est rendu possible par une modification proposée par Steve Frécinaux : DotClear : permaliens sans numéros de billets. Mais il y a moyen d'aller plus loin : supprimer "index.php" - qui à mon sens allonge inutilement l'URL et n'apporte aucune information pertinente - et supprimer l'indication de date.

Avant: http://www.atelierphp5.com/index.php/2005/01/03/8-url-rewriting-friendly-url
Après : http://www.atelierphp5.com/url-rewriting-friendly-url

Le mécanisme de suppression passe par l’utilisation du fichier .htaccess : à l'exception d'expressions qui correspondent à des fichiers ou des répertoires spécifiques, toutes les pages demandées sont redirigées vers le fichier index.php.

RewriteCond %{REQUEST_URI} !^/robots.txt
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} !^/atom.php
RewriteCond %{REQUEST_URI} !^/rss.php
RewriteCond %{REQUEST_URI} !^/tb.php
RewriteCond %{REQUEST_URI} !^/ecrire/
RewriteCond %{REQUEST_URI} !^/images/
RewriteCond %{REQUEST_URI} !^/themes/
RewriteRule ^(.*)$ /index.php [L]

Il "suffit" ensuite de récupérer les arguments renvoyés au fichier index.php et effectuer quelques traitements additionnels. Dans les modifications à effectuer il faut par exemple vérifier si un billet (ou une catégorie) correspondant à l'adresse demandée existe ou non. Ce test requiert une requête SQL supplémentaire.

Pour aller encore plus loin, pourquoi utiliser la même URI pour les flux de syndication associés ?

http://www.atelierphp5.com/url-rewriting-friendly-url.html
http://www.atelierphp5.com/url-rewriting-friendly-url.rss
http://www.atelierphp5.com/url-rewriting-friendly-url.xml
http://www.atelierphp5.com/url-rewriting-friendly-url.ping

Les adresses faisant référence à des contenus similaires, ont (logiquement) des adresses similaires. La différence d'"extension" (html/rss/xml) permet de distinguer le type de document. On pourrait utiliser des "extensions" arbitraires. Cependant utiliser des extensions courantes permet, par exemple, aux aspirateurs web de récupérer une copie statique du site en local et pouvoir rendre cette copie disponible facilement. L'extension .html (.rss, ou .xml) assure que ces fichiers seront associés aux applications ad hoc.

Faisons en sorte aussi que la structure des dates corresponde à l'arborescence du site:

http://www.atelierphp5.com/2005.html :
=> derniers billets de 2005

http://www.atelierphp5.com/2005/01.html :
=> derniers billets de janvier 2005

http://www.atelierphp5.com/2005/01/03.html :
=> derniers billets du 3 janvier 2005

http://www.atelierphp5.com/Weblog/2005/01/03.html :
=> derniers billets du 3 janvier 2005 de la catégorie Weblog

Les URI ne contiennent plus que des informations pertinentes. Les voilà amicales... A la vue d'une URI, on devine tout de suite à quel à endroit de l'arborescence et à quel type de document il est fait référence. Mieux : l'arborescence du site est reproductible pour une consultation hors-ligne. Statique. Pour une présentation depuis une clé USB par exemple...

Evidemment, cette réécriture des URL pose quelques problèmes :

• la compatibilité avec les anciennes adresses;
• les coûts engendrés : une requête SQL supplémentaire + des traitements additionnels + des modifications à effectuer + un charge serveur (légèrement) plus importante....

Sur ce site, ces problèmes sont résolus de manière pragmatique : d'une part il n'y a aucun billet antérieur à la transformation et d'autre part ce site recourt à un cache de page, en plus du cache SQL et du cache http. Mais qu’en serait-il sur un site autrement plus (inter-)actif ? Un forum de discussion par exemple ? En relation avec le projet phpStudio, la transformation des URL entraîne une série de questions :

• Quel avantages apportent ces URI ?
• Quel format d'URL adopter pour le projet phpStudio ?
• Les URL expressives ont-elles un sens sur des forums de discussion ?
• Quelqu'un a-t-il déjà tenté l’expérience ?
• Sur un forum de discussion, qui choisirait les URI ? L'utilisateur ? Le programme ?
• ...