L'auteur — Sir Tim Berners-Lee, inventeur des URI, URL, HTTP, HTML et du Web, actuellement directeur du W3C. L'article a été rédigé en 1998.

Quel URI peut-on considérer comme « cool » ?
Celle qui ne change pas.
Comment les URI changent-elles ?
Les URI ne changent pas : ce sont les gens qui les modifient.

En théorie, les gens n'ont aucune raison de modifier les URI (ou de cesser de maintenir les documents), mais en pratique, il y en a des millions.

Théoriquement, le propriétaire nominal d'un espace de noms de domaine possède effectivement cet espace et, par conséquent, tous les URI qu'il contient. À part en cas d'insolvabilité, rien n'empêche le titulaire d'un nom de domaine de le conserver. Et théoriquement, l'espace URI sous votre nom de domaine est entièrement sous votre contrôle, vous pouvez donc le rendre aussi stable que vous le souhaitez. En grande partie, la seule raison valable pour laquelle un document peut disparaître d'Internet est que l'entreprise propriétaire du nom de domaine a fermé boutique ou n'est plus en mesure de faire fonctionner son serveur. Alors pourquoi y a-t-il tant de liens morts dans le monde ? En partie, c'est simplement un manque de prévoyance. Voici quelques raisons que l'on peut entendre :

Nous avons simplement réorganisé le site pour l'améliorer.

Pensez-vous vraiment que les anciens URI ne peuvent plus fonctionner ? Si c'est le cas, vous les avez mal choisis. Pensez à l'avenir pour que les nouveaux restent après la prochaine refonte.

Nous avons tellement de matériel que nous ne pouvons pas suivre ce qui est obsolète, ce qui est confidentiel et ce qui est encore pertinent, donc nous avons pensé qu'il serait mieux de tout déconnecter.

Je ne peux que vous plaindre. Le W3C a traversé une période où nous devions soigneusement examiner les archives pour des questions de confidentialité avant de les rendre publiques. La décision doit être bien réfléchie à l'avance : assurez-vous de documenter pour chaque document un cercle de lecteurs acceptable, une date de création et, idéalement, une durée de conservation. Conservez ces métadonnées.

Eh bien, nous avons constaté qu'il fallait déplacer des fichiers…

C'est l'une des excuses les plus pitoyables. Beaucoup ignorent que les serveurs web vous permettent de gérer la connexion entre l'URI d'un objet et son emplacement réel dans le système de fichiers. Imaginez l'espace URI comme un espace abstrait, parfaitement organisé. Ensuite, mappez-le à n'importe quelle réalité que vous utilisez réellement pour le mettre en œuvre. Puis communiquez-le à votre serveur web. Vous pouvez même écrire un fragment de votre serveur pour faire tout cela correctement.

John ne prend plus en charge ce fichier, c'est maintenant Jane qui le fait.

Le nom de John était-il dans l'URI ? Non, il était juste dans son répertoire ? D'accord.

Auparavant, nous utilisions un script CGI pour cela, et maintenant nous utilisons un programme binaire.

Il existe une idée folle selon laquelle les pages créées par des scripts doivent être placées dans la zone "cgibin" ou "cgi". Cela révèle le mécanisme de la façon dont vous exécutez votre serveur web. Vous changez le mécanisme (même en conservant le contenu), et hop — tous vos URI changent.

Prenons par exemple la National Science Foundation (NSF) :

Documents en ligne de la NSF

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

La première page pour commencer à consulter les documents ne restera manifestement pas la même dans quelques années. cgi-bin, oldbrowse et pl — tout cela donne des indices sur comment-nous-le-faisons-maintenant. Si vous utilisez une page pour trouver un document, vous obtiendrez également un résultat médiocre :

Rapport du groupe de travail sur la cryptologie et la théorie du codage

http://www.nsf.gov/cgi-bin/getpub?nsf9814

pour la page d'index du document, bien que le document html lui-même soit bien meilleur :

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

Ici, le titre pubs/1998 donnera à tout futur service d'archivage une bonne clé pour comprendre le fonctionnement de l'ancienne classification des documents de 1998. Bien qu'en 2098, les numéros de documents puissent sembler différents, je peux imaginer que cet URI sera toujours valide, et cela n'entravera en rien la NSF ou toute autre organisation qui maintiendra l'archive.

Je ne pensais pas que les URL devaient être permanentes — il y avait des URN.

C'est probablement l'un des pires effets secondaires de la discussion sur les URN. Certains pensent qu'en raison des recherches sur un espace de noms plus permanent, ils peuvent se permettre d'être négligents avec les liens cassés, car « les URN résoudront tout cela ». Si vous êtes l'une de ces personnes, laissez-moi vous décevoir.

La plupart des schémas URN que j'ai vus ressemblent à un identifiant d'autorité, suivi soit d'une date et d'une chaîne que vous choisissez, soit simplement d'une chaîne que vous choisissez. Cela ressemble beaucoup à une URI HTTP. En d'autres termes, si vous pensez que votre organisation sera capable de créer des URN durables, prouve-le dès maintenant en les utilisant pour vos URI HTTP. Il n'y a rien dans HTTP qui rendrait votre URI instable. Seule votre organisation le peut. Créez une base de données qui associe l'URN du document au nom de fichier actuel, et laissez le serveur web l'utiliser pour extraire réellement les fichiers.

Si vous êtes arrivé à ce stade, alors si vous n'avez pas le temps, l'argent et les contacts pour développer un logiciel, vous pouvez faire la déclaration d'excuse suivante :

Nous voulions, mais nous n'avons tout simplement pas les outils nécessaires.

C'est vraiment dommage. Je suis tout à fait d'accord. Ce que vous devez faire, c'est obliger le serveur web à traiter instantanément l'URI permanent et à renvoyer le fichier, peu importe où il est actuellement stocké dans votre système de fichiers fou. Vous voulez stocker tous les URI dans un fichier en tant que vérification et maintenir constamment la base de données à jour. Vous souhaitez conserver les relations entre les différentes versions et traductions d'un même document, ainsi que maintenir un enregistrement indépendant de somme de contrôle pour garantir la protection contre la corruption de fichier due à une erreur accidentelle. Et les serveurs web ne sont tout simplement pas livrés avec ces fonctionnalités. Lorsque vous souhaitez créer un nouveau document, votre éditeur vous demande de spécifier l'URI.

Vous avez besoin de la capacité à modifier la propriété, l'accès au document, le niveau de sécurité au niveau d'archivage, etc., dans l'espace URI sans modifier l'URI.

Tout cela est très mal. Mais nous allons réparer cela. Au W3C, nous utilisons la fonctionnalité Jigedit (serveur Jigsaw pour l'édition), qui suit les versions, et nous expérimentons avec des scripts de création de documents. Si vous développez des outils, des serveurs et des clients, faites attention à ce problème !

Cette excuse s'applique également à de nombreuses pages du W3C, y compris celle-ci : alors faites ce que je dis, et non ce que je fais.

Pourquoi cela devrait-il m'inquiéter ?

Lorsque vous modifiez l'URI de votre serveur, il est impossible de savoir qui a des liens vers l'ancien URI. Cela peut être des liens provenant de pages web ordinaires. Des favoris vers votre page. L'URI a pu être griffonné sur les marges d'une lettre à un ami.

Lorsque quelqu'un clique sur un lien qui est cassé, il perd généralement confiance dans le propriétaire du serveur. Il est également déçu - à la fois émotionnellement et réellement - de ne pas pouvoir atteindre son objectif.

Beaucoup de gens se plaignent régulièrement des liens cassés, et j'espère que les dommages sont évidents. J'espère que les dégâts réputationnels pour le responsable du serveur où le document a disparu sont également clairs.

Alors que dois-je faire ? Concevoir un URI.

Il est de la responsabilité du webmaster de concevoir des URI qui pourront être utilisés dans 2 ans, dans 20 ans, dans 200 ans. Cela nécessite réflexion, organisation et détermination.

Les URI changent lorsque des informations sont modifiées. Il est très important de savoir comment vous les concevez. (Quoi, concevoir un URI ? Je dois penser à concevoir un URI ? Oui, vous devez y réfléchir). Concevoir signifie principalement ne pas inclure d'informations dans l'URI.

La date de création du document - la date de délivrance de l'URI - est une donnée qui ne changera jamais. Elle est très utile pour différencier les requêtes utilisant le nouveau système de celles utilisant l'ancien système. C'est un bon point de départ pour l'URI. Si une date est mentionnée sur le document, même si le document sera pertinent à l'avenir, c'est un bon début.

La seule exception est la page qui est délibérément considérée comme la « dernière » version, par exemple pour toute l'organisation ou une grande partie de celle-ci.

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

C'est la dernière colonne de Money Daily dans le magazine Money. La raison principale pour laquelle cette URI n'a pas besoin de date est qu'il n'y a aucune raison de conserver un URI qui survivra au magazine. La notion de Money Daily disparaîtra lorsque Money disparaîtra. Si vous souhaitez faire référence au contenu, vous devez le référencer séparément dans les archives :

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

(Cela a fière allure. Cela suppose que "money" aura la même signification pendant toute l'existence de pathfinder.com. Il y a une duplication de "98" et un ".html" inutile, mais sinon cela ressemble à un URI solide.

À laisser de côté

Tout ! À part la date de création, en mettant quoi que ce soit dans l'URI, vous invitez d'une manière ou d'une autre aux problèmes.

• Nom de l'auteur. L'attribution peut changer avec l'apparition de nouvelles versions. Les gens quittent les organisations et transmettent des choses à d'autres.
• Objet. C'est très compliqué. Cela semble toujours bon au début, mais cela change étonnamment rapidement. Je vais en parler plus en détail ci-dessous.
• Statut. Des catalogues tels que 'ancien', 'brouillon', etc., sans parler de 'dernier' et 'super', apparaissent dans tous les systèmes de fichiers. Les documents changent de statut - sinon, il ne serait pas logique de créer des brouillons. La dernière version d'un document a besoin d'un identifiant constant, peu importe son statut. Gardez le statut séparé du nom.
• Accès. Au W3C, nous avons séparé le site en sections pour le personnel, les membres et le public. Cela semble bien, mais bien sûr, les documents commencent comme des idées d'équipe des employés, discutés avec les membres, puis deviennent d'un accès public. C'est vraiment frustrant si chaque fois qu'un document est ouvert à une discussion plus large, tous les anciens liens vers celui-ci sont cassés ! Passons maintenant à un simple code de date.
• Extension de fichier. Un phénomène très courant. 'cgi', même '.html' changeront à l'avenir. Peut-être que dans 20 ans, vous n'utiliserez plus HTML pour cette page, mais les liens d'aujourd'hui doivent encore fonctionner. Les liens canoniques sur le site W3C n'utilisent pas d'extension (comment c'est fait).
• Mécanismes logiciels. Dans l'URI, cherchez 'cgi', 'exec' et d'autres termes qui crient 'regardez quel logiciel nous utilisons'. Quelqu'un veut-il consacrer toute sa vie aux scripts Perl CGI ? Non ? Alors supprimez l'extension .pl. Lisez le guide du serveur sur comment faire cela.
• Nom du disque. Allez donc ! Mais je l'ai déjà vu.

Donc le meilleur exemple de notre site est simplement

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

… le rapport du procès-verbal des présidents du W3C.

Sujets et classification par thème

Je vais expliquer plus en détail ce danger, car c'est l'une des choses les plus difficiles à éviter. En général, les sujets se retrouvent dans l'URI lorsque vous classez vos documents par tâche effectuée. Mais cette classification évoluera avec le temps. Les noms de domaines changeront. Chez W3C, nous avions l'intention de changer MarkUP en Markup, puis en HTML, pour refléter le contenu réel de la section. De plus, il y a souvent un espace de noms plat ici. Dans 100 ans, êtes-vous sûr de ne rien vouloir réutiliser ? Dans notre courte vie, nous avons déjà voulu réutiliser des « Histoires » et des « Feuilles de style », par exemple.

C'est une manière tentante d'organiser un site web — et vraiment une manière séduisante d'organiser quoi que ce soit, y compris l'ensemble du Web. C'est une excellente solution à moyen terme, mais elle présente de graves inconvénients à long terme.

En partie, les raisons résident dans la philosophie du sens. Chaque terme dans une langue est un objet potentiel de classification, et chaque personne peut avoir une perception différente de ce qu'il signifie. Étant donné que les relations entre les sujets ressemblent davantage à une toile d'araignée qu'à un arbre, même ceux qui sont d'accord avec la toile peuvent choisir une représentation différente de l'arbre. Ce sont mes (souvent répétées) observations générales sur les dangers de la classification hiérarchique comme solution générale.

En fait, lorsque vous utilisez un nom de sujet dans un URI, vous vous engagez à une certaine classification. À l'avenir, vous pourriez préférer une autre option. Dans ce cas, l'URI sera sujet à violation.

La raison d'utiliser un domaine thématique comme partie de l'URI est que la responsabilité des sous-sections de l'espace URI est généralement déléguée, et vous avez alors besoin du nom de l'autorité organisationnelle — d'un département, d'un groupe ou de quelque chose d'autre responsable de ce sous-espace. C'est un lien URI à la structure organisationnelle. En général, cela reste sécurisé seulement si, plus à gauche, l'URI est protégé par une date : 1998/pics peut signifier pour votre serveur « ce que nous entendions en 1998 sous pics », et non « ce que nous avons fait en 1998 avec ce que nous appelons maintenant pics ».

N'oubliez pas le nom de domaine

N'oubliez pas que cela concerne non seulement le chemin dans l'URI, mais aussi le nom du serveur. Si vous avez des serveurs distincts pour différentes choses, gardez à l'esprit que cette séparation ne pourra pas être modifiée sans détruire de nombreux liens. Certaines erreurs classiques comme « regardez quel logiciel nous utilisons aujourd'hui » – les noms de domaine « cgi.pathfinder.com », « secure », « lists.w3.org ». Ils ont été créés pour faciliter l'administration des serveurs. Peu importe si le domaine représente une certaine subdivision de votre entreprise, le statut du document, le niveau d'accès ou le niveau de sécurité, soyez très, très prudent avant d'utiliser plus d'un nom de domaine pour plusieurs types de documents. N'oubliez pas que vous pouvez cacher de nombreux serveurs web derrière un seul serveur web visible en utilisant des redirections et du proxy.

Oui, et pensez également à votre nom de domaine. Vous ne voulez pas qu'on vous cite comme étant soap.com après avoir changé de gamme de produits et cessé de produire du savon (je m'excuse auprès de celui qui possède soap.com en ce moment).

Conclusion

Conserver un URI pendant 2, 20, 200 ou même 2000 ans n'est évidemment pas aussi simple qu'il n'y paraît. Cependant, sur toute internet, les webmasters prennent des décisions qui compliquent réellement cette tâche à l'avenir. Cela se produit souvent parce qu'ils utilisent des outils dont le but est de présenter le meilleur site uniquement à ce moment-là – et personne n'a pris en compte ce qui se passera avec les liens quand tout changera. Cependant, l'idée ici est que beaucoup, beaucoup de choses peuvent changer, et vos URI peuvent et doivent rester les mêmes. Cela n'est possible que si vous réfléchissez à la manière dont vous les créez.

Voir aussi :

• Le tirade de Jakob Nielsen sur le même sujet

Extensions

Comment supprimer les extensions de fichiers...

...des URI dans le serveur web actuel basé sur des fichiers ?

Si vous utilisez, par exemple, Apache, vous pouvez le configurer pour faire correspondre le contenu. Vous conservez l'extension de fichier (par exemple, .png) dans le fichier (par exemple, mydog.png), mais il est possible de référencer une ressource Web même sans cela. Ensuite, Apache vérifie le répertoire pour trouver tous les fichiers avec ce nom et n'importe quelle extension, et peut également choisir le meilleur d'un ensemble (par exemple, GIF et PNG). Il n'est en fait pas nécessaire de placer différents types de fichiers dans des répertoires distincts, car la négociation de contenu ne fonctionnera pas si vous le faites.

• Configurez votre serveur pour la négociation de contenu
• Faites toujours des liens vers des URI sans extension

Les liens avec des extensions fonctionneront toujours, mais cela empêchera votre serveur de choisir le meilleur format actuellement et dans le futur.

(En réalité, mydog, mydog.png et mydog.gif — des ressources Web valides, mydog — c'est une ressource de type de contenu universel, et mydog.png et mydog.gif — des ressources de type de contenu spécifique).

Bien sûr, si vous écrivez votre propre serveur Web, il est bon d'utiliser une base de données pour lier des identifiants permanents à leur forme actuelle, mais faites attention à la croissance illimitée de la base de données.

Table d'affichage — Histoire 1 : Channel 7

Au cours de l'année 1999, j'ai suivi la fermeture des écoles en raison de la neige sur la page http://www.whdh.com/stormforce/closings.shtml. Il ne fallait pas attendre que l'information apparaisse en bas de l'écran de télévision ! J'ai mis un lien vers elle sur ma page d'accueil. Le premier gros blizzard de l'année 2000 arrive, et je vérifie la page. Il est écrit :

— À ce jour.
Actuellement, rien n'est fermé. Veuillez revenir en cas d'alertes météo.

Impossible, une tempête aussi forte. C'est drôle que la date soit absente. Mais si vous allez sur la page d'accueil du site, il y aura un gros bouton 'Écoles fermées' qui mène à une page http://www.whdh.com/stormforce/ avec une longue liste d'écoles fermées.

Peut-être ont-ils changé le système pour obtenir la liste — mais ils n'avaient pas besoin de changer l'URI.

Table d'affichage — Histoire 2 : Microsoft Netmeeting

Avec la dépendance croissante à Internet est venue l'idée intelligente d'intégrer des liens vers le site de l'éditeur dans les applications. Cela était souvent utilisé et largement abusé, mais — il est impossible de changer l'URL. Récemment, j'ai essayé un lien du client Microsoft Netmeeting 2/something dans le menu Aide/Microsoft sur le Web/Articles gratuits et j'ai obtenu une erreur 404 — réponse non trouvée du serveur. Peut-être qu'ils l'ont déjà corrigé…

©1998 Tim BL

Note historique : à la fin du 20e siècle, lorsque cela a été écrit, « cool » était un épithète d'approbation, particulièrement parmi les jeunes, indiquant la mode, la qualité ou la pertinence. Dans la précipitation, le chemin URI était souvent choisi pour sa « coolitude » plutôt que pour son utilité ou sa durabilité. Cette note est une tentative de rediriger l'énergie qui sous-tend la recherche de la coolitude.

Source : habr.com