La plupart des sites et applications sont dynamiques, et la façon la plus répandue de faire passer des informations de page en page est d’utiliser l’URL, en lui passant des paramètres (GET).
Qu’est ce qu’une URL propre ? C’est une URL qui contient des mots-clés pour les moteurs de recherche, et qui est facile à taper pour l’utilisateur (on proscrit donc les URLs à rallonge, où les paramètres foisonnent). Nous allons le voir dans cet article, avoir des URLs propres est l’une des optimisations les plus importantes à mettre en place sur son site ou application web.
Cet article présente une alternative 100% Java au module mod_rewrite d’Apache que l’on utilise habituellement pour manipuler et nettoyer les URLs : UrlRewriteFilter vous permettra d’effectuer facilement les mêmes manipulations sans Apache, directement dans votre application web Java.

Pourquoi des URLs propres ?

Pour différentes raisons :

• pour vos utilisateurs et clients, une URL lisible et facile à comprendre leur permet de deviner facilement le contenu de la page; les URLs générées par WordPress sont un bon exemple : http://blog.xebia.fr/2008/01/10/scrum-ou-xp-scrum-et-xp
• les moteurs de recherche préfèrent des URLs propres, en particulier pour une raison précise : si vous laissez de nombreuses URLs avec paramètres, vous risquez de proposer du contenu dupliqué. Le résultat est en général sans appel, le moteur de recherche va consommer une bande passante trop importante, et risque de ne pas indexer tout votre site. Pour plus d’informations, vous pouvez vous référer aux recommandations de Google.
• pourquoi révéler à vos utilisateurs la technologie sous-jacente ? inutile de laisser traîner les .do, .action ou même .jsp (certes, avec la plupart des frameworks web, il est possible de changer l’extension par défaut, mais l’intérêt de cette solution reste limité. Avec Struts, si vous remplacez les .do par des .html, vous devrez faire face à quelques soucis de configuration. Vous serez par exemple dans l’obligation de traiter différemment les vrais fichiers .html).
• sortons la machine à remonter le temps, la préoccupation n’est pas récente. Prenons pour exemple cet article de Jakob Nielsen qui date de 1999. Jakob a ajouté en 2007 une information intéressante à son article : selon une étude de Microsoft, sur les pages de résultats de recherche les utilisateurs passent 24% de leur temps à observer les URLs.

Les URLs générées par les frameworks web J2EE que nous utilisons le plus fréquemment ont besoin d’être optimisées (je n’ai jamais développé avec Tapestry, mais il semble que ce framework permette de maîtriser les URLs générées, depuis sa version 4).
Comment manipuler ces URLs pour les rendre lisibles ?On utilisera la plupart du temps le module mod_rewrite d’Apache. Si la syntaxe de configuration est assez rebutante, le module est efficace et remplit son rôle.

Seulement l’utilisation de mod_rewrite est assez contraignante sur l’environnement de développement :

• il faut installer Apache (si on peut s’en passer sur le poste de développement, on s’en passe !)
• il faut installer le module permettant de faire dialoguer Apache et le serveur d’applications
• il faut synchroniser les fichiers de configuration et les règles de ré-écriture sur les postes de tous les développeurs (en les plaçant en gestion de configuration, alors qu’à priori ils n’appartiennent pas aux sources de l’application)

Le filtre de servlet UrlRewriteFilter

L’objet de cet article est la solution aux contraintes présentées ci-dessus : la librairie OpenSource (licence BSD) UrlRewriteFilter. Ou comment bénéficier des URLs propres sur l’environnement de développement sans la lourdeur de mise en oeuvre d’un mod_rewrite sur Apache.

Comme son nom l’indique, UrlRewriteFilter est un simple filtre de servlet, vous pouvez donc l’utiliser sur votre serveur d’applications ou moteur de servlets favori. Je vous épargne l’installation et la configuration de base de la librairie, il suffit de déclarer le filtre dans le descripteur xml de votre application web.
La « magie » se situe dans le fichier de configuration urlrewrite.xml, à placer dans le répertoire WEB-INF de votre application.

Prenons un exemple : Xebia se lance dans le commerce en ligne, et le framework web utilisé génère l’URL suivante :

http://www.xebiamazon.com/categories.do?categorie=livres

Je préférerais proposer aux moteurs de recherches et à mes clients cette URL :

http://www.xebiamazon.com/categories/livres

Voici la configuration nécessaire :

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.0//EN"
    "http://tuckey.org/res/dtds/urlrewrite3.0.dtd">
<urlrewrite>
    <rule>
       <from>^/categories/(.*)$</from>
       <to>/categories.do?categorie=$1</to>
    </rule>
</urlrewrite>

Comme vous le voyez, la syntaxe est ici la même que celle de mod_rewrite.

Si en production vous décidez de désactiver UrlRewriteFilter, vous pouvez la plupart du temps recopier les règles contenues dans le fichier de configuration urlrewrite.xml et les poser telles quelles dans votre fichier de configuration Apache. Pour vous assurer de la compatibilité de vos règles, vous pouvez utiliser une syntaxe 100% mod_rewrite (depuis la version 3.1 d’UrlRewriteFilter)
Je n’irai pas plus loin dans la multitude de possibilités de configuration qu’offrent mod_rewrite et UrlRewriteFilter, vous trouverez d’autres exemples de syntaxe et d’utilisation dans la documentation officielle de la librairie.

Un conseil si vous souhaitez utiliser UrlRewriteFilter sur une application ou un site à fort trafic, et si votre fichier de règles est volumineux : il faudra certainement recopier vos règles sur votre serveur Apache si vous voulez éviter les problèmes de performance sur votre serveur d’applications.

Les nouveautés de la version 3.2

La page d’accueil d’UrlRewriteFilter propose deux versions en téléchargement : la 2.6 stable (malheureusement absente des repositories Maven officiels au moment où j’écris ces lignes), et la version 3.2 « beta ».

Voici quelques unes des nouveautés dans la branche 3 :

• support de règles wildcard, si la syntaxe « regexp » vous rebute.
  En reprenant l’exemple du dessus :

  <rule>
     <from>/categories/*</from>
     <to>/categories.do?categorie=$1</to>
  </rule>
  

• mapping des URLs sur des méthodes de servlets, ce qui permet ainsi d’aller plus loin que le simple mapping de servlets standard dans le web.xml.
• configuration possible par annotations
  Le mapping des URLs sur les servlets peut être fait grâce à des annotations, qui vont ensuite permettre de générer le fichier de configuration (elles ne sont pas utilisées au runtime).
  Exemple :

  @HttpUrl("^/categories/(.*)$")
  public void doSomething(String category)
  

• support des règles « mod_rewrite » dont j’ai parlé plus haut

En attendant la stabilisation de la branche v3, la version stable 2.6 devrait cependant parfaitement répondre à vos besoins de ré-écriture d’URLs.

Quelques articles pour aller plus loin

• Matt Raible avait traité le sujet il y a quelques mois, et vient de poster un exemple d’utilisation avec GWT
• Exemple d’utilisation d’UrlRewriteFilter avec Spring MVC
• Un autre exemple avec JBoss Seam
• Le groupe Google d’UrlRewriteFilter