Les URLs sympas ne changent pas

Qu'est-ce qu'une URL sympa ?
Une URI sympa est une URI qui ne change pas.
Quels sont les types d'URI qui changent ?
Les URIs ne changent pas : Ce sont les gens qui les changent.

En théorie, il n'y aucune raison pour que les gens changent les URIs (ou arrêtent de maintenir les documents), mais en pratique, il existe des millions de raisons.

En théorie, le propriétaire du nom de domaine possède l'espace déclaré par le nom de domaine, ainsi que toutes les URIs qui y sont comprises. Excepté si la personne devient non solvable, rien n'interdit au propriétaire du nom de domaine de conserver le nom. Et en théorie, l'espace d'URI défini par votre nom de domaine est totalement sous votre contrôle, ainsi il est tout à fait possible de le rendre aussi stable que vous le désirez. L'unique bonne raison pour laquelle un document peut disparaître du Web est que la société qui possède le nom de domaine dépose le bilan ou n'a plus les moyens de gérer la bonne marche du serveur. Alors pourquoi existe-t-il tant de liens cassés dans le monde ? Habituellement, juste par manque de prévoyance. Voici une liste des arguments les plus souvent rencontrés :

Nous venons juste de finir de réorganiser notre site web afin de l'améliorer.

Pensez-vous réellement que les anciennes URIs ne peuvent pas être maintenues? Si oui, vous les avez très mal choisies au départ. Choisissez alors les nouvelles de manière à les conserver lors de la prochaine amélioration de votre site.

Nous avons tant de données que nous ne pouvons pas tracer celles qui sont obsolètes ou qui sont confidentielles et celles qui sont publiques, c'est pourquoi, nous avons pensé qu'il était préférable de faire disparaître l'ensemble.

C'est un argument que je peux comprendre - le W3C est passé par une période similaire, lorsque nous avons eu à extraire des données confidentielles contenues dans les archives avant de les rendre publiques. La solution prudente à adopter - soyez sûr que chaque document individuel possède une distribution adéquate, sa date de création et idéalement sa date d'expiration. Conservez ces métadonnées.

Hmmm, nous avons pensé qu'il était nécessaire de déplacer les fichiers...

C'est l'une des excuses qui a le moins de sens. Beaucoup de gens ne savent pas que les serveurs web tels qu'Apache vous donne tout le contrôle nécessaire pour maintenir une relation souple entre l'URI d'un objet et l'endroit physique où se trouve réellement le fichier dans le système. Vous devez penser l'espace d'URI comme un espace abstrait, parfaitement organisé. Créez alors une cartographie de ce que vous avez besoin pour le mettre en œuvre. Puis, communiquez-le à votre serveur. Vous pouvez même écrire quelques morceaux d'informations pour le faire vous même sur le serveur de manière correcte.

Jean ne maintient plus ce fichier dorénavant, c'est Jeanne qui le fait maintenant.

Pourquoi l'URI contenait le nom de Jean à l'intérieur ? Le document était dans son répertoire ? Je vois.

Nous avions l'habitude d'utiliser un script cgi pour ceci et maintenant nous utilisons un programme binaire.

Il y a une idée saugrenue que les pages produites par des scripts doivent résider dans l'espace "cgi-bin" ou "cgi". Ceci expose la manière que vous avez de gérer votre propre serveur. Vous changez le mécanisme de gestion (même en conservant le contenu) et hop ! toutes vos URIs changent.

Par exemple, prenez la Fondation Nationale pour la Science (National Science Foundation) :

NSF Documents en ligne
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

la page principale pour chercher les documents, est typiquement une page dans lequel on ne peut pas savoir si elle sera encore existante dans quelques années. "cgi-bin" et "oldbrowse" et ".pl" sont tous des éléments qui sont clairement des témoins de la manière de pratiquer maintenant. Par exemple, si vous utilisez la page pour trouver un document, vous obtenez en premier un document dont l'URI n'est pas bonne.

Rapport du groupe de travail sur la Cryptologie et la théorie de programmation. (Report of Working Group on Cryptology and Coding Theory)
http://www.nsf.gov/cgi-bin/getpub?nsf9814

Si vous passez par la page d'index, le document HTML en lui même est bien meilleur :

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Si l'on prend le temps d'observer, on remarque que le chemin "pubs/1998" donne à tous futurs services d'archives une bonne indication du schéma de classification en cours pour les vieux documents de 1998. Bien qu'en 2098 la numération des documents sera différente, j'imagine très bien que cette URI sera toujours valide, et que la NSF ou qui que ce soit qui gérera les archives n'aura aucun problème avec celle ci.

Je ne pense pas que les URLs doivent être persistantes - ceci étaient les URNs.

C'est sûrement l'un des travers les plus importants des discussions sur les URNs. Certains semblent penser que parce qu'il y a actuellement une recherche sur la manière de rendre plus persistant les espaces de nom, ils peuvent être plus laxistes sur les liens en pensant que les "URNs résoudront tout cela". Si vous êtes l'une de ces personnes, alors permettez-moi de briser vos illusions.

La plupart des schèmes d'URN que j'ai pu voir ressemblaient à quelque chose de ce type : un identifiant d'autorité ID suivi ou bien par une date ou bien un nom de votre choix, ou seulement par un nom de votre choix. Cela ressemble comme deux gouttes d'eau à une URI HTTP. En d'autres mots, si vous pensez que votre organisation sera capables de créer des URNs qui persisteront, alors prouvez le en le faisant dès aujourd'hui et en les utilisant dans les URIs HTTP. Il n'y a rien dans le protocole HTTP qui rend vos URIs instable. C'est la façon dont vous organisez. Créez une base de données qui établit les relations entre l'URN du document et le nom courant du fichier, et paramétrez le serveur web pour qu'il utilise réellement ceci pour servir les fichiers.

Si vous avez atteint ce point, et à moins que vous n'avez ni le temps et l'argent, et ni les contacts pour réaliser ce type de logiciels, alors vous prônerez l'excuse suivante :

Nous aimerions bien, mais nous n'avons pas les bons outils pour le faire.

En voici une que je peux comprendre. J'approuve totalement. Ce dont vous avez besoin est un serveur web qui capte l'URI persistante immédiatement et délivre en retour le fichier, quelque soit le lieu où votre incroyable système de fichier l'a stocké pour le moment. Vous pourriez vouloir stocker l'URI dans le fichier comme vérification, et garder constamment la base de données en accord avec la réalité. Vous pourriez vouloir conserver les relations entre les différentes versions et traductions du même document, et vous pourriez vouloir conserver un enregistrement indépendant du "checksum" pour vous prémunir de la détérioration d'un fichier par erreur accidentelle. Et les serveurs web n'offrent pas par défauts ces fonctionnalités. Lorsque vous voulez créer un nouveau document, votre éditeur vous demande une URI plutôt que de vous dire.

Vous avez besoin de changer des choses comme les droits, l'accès, le niveau d'archive, le niveau de sécurité, et tant d'autres choses, d'un document dans l'espace d'URI sans changer l'URI.

Dommage. Mais nous avons cela ici. Au W3C, nous utilisons la fonctionnalité Jigedit (le serveur Jigsaw utilisé pour l'édition) qui tracent les versions, et que nous utilisons avec des scripts de création de document. If vous êtes un créateur d'outils, serveurs ou clients, prenez des notes !

C'est une excellente raison, qui s'appliquent par exemple à de nombreuses pages du W3C, y compris celle-ci : Que dois je dire, qu'est-ce je ne peux pas dire ?

Pourquoi devrais-je m'en soucier ?

Lorsque vous changez une URI sur votre serveur, vous ne pouvez jamais totalement savoir qui a des liens vers l'ancienne URI. Il est possible que des liens existent depuis d'autres pages web. Ils peuvent également avoir mis votre page en signets. Ils ont peut-être envoyé l'URI en référence dans une lettre à un ami.

Lorsqu'une personne suit un lien et qu'il n'est plus disponible, celle-ci perdra de la confiance envers le propriétaire du serveur. Elle ressent également une frustration - émotionnelle et pratique de ne pas pouvoir atteindre son but.

Il y a suffisamment de personnes qui se plaignent des liens cassés pour penser que le problème est évident. It est également assez clair que la réputation du gestionnaire est touchée lorsque les documents disparaissent.

Donc que devrais-je faire ? Concevoir des URIs

Cela fait partie des tâches du webmaster d'allouer les URIs sur lesquelles vous pourrez compter encore dans 2 ans, dans 20 ans, dans 200 ans. Ceci réclame réflexion, organisation et implication.

Les URIs changent lorsque l'information contenue dedans change. Leur création est donc critique. (Comment, concevoir une URI ? J'ai à concevoir des URIs ? Oui, vous devez y pensez.). Concevoir signifie la plupart mettre l'information à part.

La date de création d'un document - la date à laquelle l'URI existe - est l'une des choses qui ne changera jamais. C'est très utile pour séparer les requêtes qui utilisent le nouveau système de celles qui utilisent l'ancien. C'est donc une bonne méthode pour commencer une URI. Si un document est d'une manière ou d'une autre daté, et même s'il est d'un intérêt certain pour plusieurs générations, alors la date est un bon départ.

L'unique exception est une page qui est clairement une page "dernières nouvelles, par exemple, pour l'ensemble d'une organisation ou pour une grande partie de celle ci.

http://www.pathfinder.com/money/moneydaily/latest/

est la dernière version de la colonne "Money daily" du magazine "Money". La raison principale pour la non nécessité de date dans cette URI est qu'il n'existe aucune raison de persistance de l'URI pour la dernière information du magazine. Le concept de "Money" du jour disparaît si Money n'est plus publié. Si vous voulez établir un lien vers le contenu, vous préférez établir le lien avec le contenu de l'archive tel que

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(Pas mal. Considérons que "money" signifie la même chose au long de la vie de pathfinder.com. Il y a une duplication de "98" et de ".html" qui sont inutiles, mais en dehors de ça, cela ressemble à une bonne URI).

NdT : Pathfinder n'a malheureusement pas su conserver la stabilité de l'URL, ou plutôt lors du rachat de la société, celle-ci n'a pas été maintenu, illustrant parfaitement le problème présenté ici.

Que doit on laisser tomber ?

Tout ! Après la date de création, ajouter toute type d'information dans le nom est d'une manière ou d'une autre ouvrir la possibilité de problèmes.

• Nom des auteurs- L'auteur peut changer de version en version. Les personnes quittent les organisations et passent le relais.
• Sujet. C'est une question difficile. Cela paraît toujours bon au moment de la publication mais elle change de façon surprenante très vite. J'en discute plus bas.

• Statut- les répertoires tels que "vieux" ou "brouillon" out similaires, sans mentionner "dernièrement" ou "cool" sont présents sur les fichiers systèmes. Les documents changent de statut - si ce n'était pas le cas, il n'y aurait aucune raison de produire des versions de brouillons. La dernière version d'un document doit posséder un identificateur permanent quelque soit son statut. Ne mettez donc pas le statut dans le nom.

  NdT : Pour gérer un espace daté et les différentes versions d'un document de ses différentes étapes de brouillon à sa version finale (en sachant que le final peut toujours évoluer), voici une technique simple. Imaginer que vous rédigiez la première version de votre document le 11 septembre 2001. Vous pouvez alors donner le nom suivant :

  http://www.example.org/2001/09/11-info.html

  Et puis vous changez le contenu de ce document de façon majeure le 10 février 2002. Vous pouvez créer un nouveau document se trouvant à :

  http://www.example.org/2002/02/10-info.html

  Dans ce nouveau document, n'oubliez pas de mentionner une référence vers l'ancienne version du document à la fin ou au début. Par exemple, version précédente : http://www.example.org/2001/09/11-info.html. Nous avons résolu le problème de la gestion des versions mais pas celui de l'URL unique. le module "mod_rewrite" de Apache peut vous aider à résoudre ce problème. En effet dans chaque document que vous éditez vous pouvez ajouter une phrase dernière version : http://www.example.org/info. Et vous pouvez modifier le fichier httpd.conf de votre serveur Apache.

     RewriteEngine on
  #  ancienne règle du 11 septembre 2001
  # RewriteRule /info(.*) /2001/09/11-info$1
  #
     RewriteRule /info(.*) /2002/02/10-info$1
  

• Accès. Au W3C, nous avons divisé le site en trois espaces "Team access" (Equipe), "Member access" (Membre), "Public access" (Public). Cela semble raisonnable à première vue, mais bien sûr, un document peut démarrer sa vie comme l'émergence d'idées issues de l'équipe, est ensuite discuté par les membres, et finalement émerge de façon publique. Cela devient un problème évident, si chaque fois qu'un document est ouvert à une discussion plus large, tous les liens anciens deviennent caduques ! Nous avons donc adopté un simple système basé sur les dates maintenant.

• Extension de nom de fichier. C'est quelque chose de très commun. "cgi", ou même ".html" est quelque chose qui changera. Peut-être que pour cette page particulière, vous n'utiliserez pas HTML dans une vingtaine d'années, mais vous pouvez dès aujourd'hui vouloir que les liens restent valides. La forme canonique pour écrire des liens au W3C est de ne pas utiliser les extensions. (Comment ?)

  NdT : Vous pouvez utiliser conneg par exemple sur Apache qui est un module qui permet la négociation de contenu et donc de ne pas mettre l'extension pour le nom d'un fichier.

• Mécanismes logiciels. Regardez "cgi", "exec" et autres facilités tels que "regardez les logiciels que nous utilisons" dans les URIs. Est-ce qu'une personne s'astreindra à utiliser des scripts cgi perl toute leur vie ? Certainement pas ! Enlevez le ".pl". Lisez le manuel du serveur pour apprendre à le faire.
• Nom du disk - donnez moi cinq minutes ! Mais je vous assure que je l'ai déjà vu.

Donc un bon exemple tiré simplement de notre site

http://www.w3.org/1998/12/01/chairs

Le procès verbal d'une réunion du président de séance de W3C.

Catégories et classification par sujet

Je vais développer ce piège avec plus de détails car c'est une des choses les plus difficiles à éviter. Typiquement, les catégories finissent par apparaître dans les URIs quand vous classifiez vos documents en fonction du découpage du travail que vous effectuez. Mais ce découpage changera. Les noms des sections changeront. Au W3C, nous voulions changer "MarkUp" par "Markup" et ensuite pour "HTML" afin d'exprimer le contenu actuel de la section. Vous devez également prendre garde au fait que c'est un espace de nom plat. Dans 100 ans, êtes vous sure que vous ne voudrez pas réutiliser une partie ? Nous voulions réutiliser "History" et "Stylesheets" par exemple dans notre histoire courte.

C'est une façon séduisante d'organiser un site web - et bien sûr une façon d'organiser toute chose, y compris un site web complet. C'est une belle solution à moyen terme mais cache de sérieuses difficultés sur le long terme.

Les raisons de cette organisation réside dans la philosophie de la signification. Chaque terme dans le langage est un sujet de regroupement possible, et chaque personne peut avoir une idée différente de sa signification. Parce-que les relations entre les sujets sont de type web plutôt que de type arbre, même pour les personnes en accord sur un web, peuvent posséder des représentations en arbre différente. Il y a un danger réel à l'organisation sous forme de classification en tant que solution générale.

Effectivement, quand vous utilisez un nom de catégorie dans une URI, vous vous enfermez vous même dans un type de classification. Vous pouvez vouloir dans le futur un autre type de classification. L'URI possède alors potentiellement un problème.

Les sous-parties d'un espace d'URI qui est typiquement attribué à une fonction donnée est une des raisons qui motive l'utilisation d'une catégorie dans une URI, et ainsi vous serez amené à utiliser ce sous espace pour catégoriser l'URI. Cela colle votre URI à une structure d'organisation. On prend par exemple peu de risques, lorsque résident dans un espace daté de l'URI (c'est à dire à gauche de celle ci) : 1998/pics peut être utilisé pour exprimer sur votre serveur "que voulions nous dire en 1998 par pics", plutôt que "qu'est ce nous avons fait en 1998 et que nous référons maintenant comme pics."

N'oubliez pas le nom de domaine.

Souvenez vous que tout cela s'applique non seulement au "chemin" d'une URI mais également au serveur de nom. Si vous possédez différent serveurs pour vos données, souvenez vous que ces décisions seront impossible à changer sans détruire un grand nombre de liens. Quelques noms de domaine du type "hé, regardez quel logiciel nous utilisons aujourd'hui" sont "cgi.pathfinder.com", "secure", "lists.w3.org". Ils ont été choisis pour faciliter l'administration des serveurs. Bien qu'ils représentent des divisions dans votre compagnie, dans le statut des documents, ou niveau d'accès, ou niveau de sécurité, soyez très, très prudent avant d'utiliser plus d'un seul nom de domaine pour plus d'un type de document. Souvenez que vous pouvez cacher beaucoup de serveurs Web derrière un serveur web apparent en utilisant la redirection et les serveurs proxys.

Oh, et pensez à votre nom de domaine. Si votre nom n'est pas savon, voudrez-vous être connu par "savon.com" même lorsque votre ligne de produit aura changé pour autre chose. (Avec toutes mes excuses pour la personne qui posséderait actuellement savon.com).

Conclusion

Gérer les URIs de façon à ce qu'elles soient toujours valides dans 2, 20, ou 200 ou même 2000 ans n'est pas aussi simple que cela paraît à première vue. Cependant, sur le Web, les webmasters adoptent des décisions qui leur rendront la vie difficile pour le futur. Souvent, c'est parce-qu'ils utilisent des outils dont la tâche principale est de créer le meilleur site web pour le moment donné, sans évaluer ce qui se passera pour les liens lorsque les choses auront changé. Le message ici est, cependant, que beaucoup, beaucoup de choses peuvent changer et vos URIs peuvent et devraient rester les mêmes. Elles resteront stable uniquement si vous y pensez au moment de les concevoir.

Voir également :

• L'avis de Jakob Nielsen sur le même sujet

Footnote

Comment puis-je enlever les extensions de nom de fichiers...

...de mes URIs dans un serveur Web basé sur les fichiers ?

Si vous utilisez par exemple, Apache, vous pouvez le paramétrer pour faire de la négociation de contenu. Vous conservez l'extension du fichier (tel que .png) sur le nom du fichier (par exemple monchien.png), mais référez à la ressource web sans l'extension. Apache alors vérifiera le répertoire pour tous les fichiers qui possède ce nom et quelque soit l'extension, et il choisit le meilleur en fonction d'un ensemble (par exemple GIF et PNG). (Vous n'avez pas forcément à mettre différent types de fichiers dans différent répertoire, en fait la négociation de contenu ne fonctionnera pas si vous le faites.)

• Paramétrez votre serveur pour faire de la négociation de contenu
• Faites toujours référence à l'URI sans l'extension

Les références qui possèdent des extensions continueront à fonctionner mais ne permettront pas à votre serveur de sélectionner la meilleure des ressources disponibles et des formats futurs.

(En fait, monchien, monchien.png et monchien.gif sont toutes des ressources Web valides. monchien est un content-type-generic (type de contenu générique). monchien.png et monchien.gif sont des content-type-specific (types de contenu spécifique).)

Bien sûr, si vous créez votre propre serveur, alors utiliser une base de données pour faire référence à des identificateurs persistants dans leur forme courante est une idée élégante -- cependant faite attention à la croissance immodérée de votre base de donnée.

Prix citron -- anecdote 1 : Canal 7

En 1999, http://www.whdh.com/stormforce/closings.shtml était une page que j'ai trouvé et qui me donnait des informations à propos des fermetures d'écoles à cause de la neige. Un autre moyen d'obtenir d'obtenir cette information sans attendre un bandeau défilant au bas de l'écran TV ! j'ai donc placé un pointeur vers cette ressource dans ma page d'accueil. Et puis en 2000 arrive la première grosse tempête, et je décide de vérifier la page. Cela disait,

"Fermeture : Il n'y a pas de fermetures actuellement. Vérifiez de nouveau lors des alertes météos."

Cela ne doit pas être une si grosse tempête. Amusant car la date est manquante. Mais si je me rends à la page d'accueil du site, il y a un gros bouton "fermeture d'école" qui m'emmène sur http://www.whdh.com/stormforce/ qui possède une liste des nombreuses écoles fermées.

Ils ont donc changé le système qui permet d'obtenir la liste des fermetures définitives - mais ils n'avaient pas besoin de changer l'URI.

Prix citron -- anecdote 2 : Netmeeting de Microsoft

Une des choses qui démontrent la dépendance de plus en plus importante au web sont les applications qui ont des mécanismes internes qui permettent de retourner vers le site web du fabricant. Ceci a été utilisé et perverti à grande échelle, mais - mais vous devez conserver l'URL identique. L'autre jour, j'ai essayé un lien à partir du logiciel client Netmeeting 2 de Miscrosoft, dans un menu "Aide/Microsoft sur le Web/Matériel gratuit" et j'ai obtenu une erreur 404 - une réponse "Pas trouvé" du serveur. Ils l'ont surement corrigé depuis...

Note historique : A la fin du 20eme siècle quand ceci a été écrit, "cool" (NdT : traduit par sympa dans le titre) était une façon de définir parmi les jeunes, une chose particulièrement à la mode, de qualité ou appropriée. Dans la précipitation du choix de notre nom de domaine ou de nos URIs nous ont parfois entraîné vers cette apparente "coolness" (attitude sympa) plutôt que vers l'utilité ou la longévité. Cette note est une tentative pour rediriger les énergies derrière la quête de la cool attitude. :).