Auteur : Sir Tim Berners-Lee, inventeur des URI, des URL, du HTTP, du HTML et du World Wide Web, et actuel directeur du W3C. Article écrit en 1998

Quel URI est considéré comme « cool » ?
Celui qui ne change pas.
Comment les URI sont-ils modifiés ?
Les URI ne changent pas : les gens les changent.

En théorie, il n’y a aucune raison pour que les gens changent d’URI (ou arrêtent de fournir des pièces justificatives), mais en pratique, il y en a des millions.

En théorie, le propriétaire nominal d'un espace de noms de domaine possède en réalité l'espace de noms de domaine et donc tous les URI qu'il contient. Hormis l’insolvabilité, rien n’empêche le propriétaire d’un nom de domaine de conserver ce nom. Et en théorie, 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. La seule bonne raison pour laquelle un document disparaît d'Internet est que la société qui possédait le nom de domaine a fait faillite ou n'a plus les moyens de faire fonctionner le serveur. Alors pourquoi y a-t-il tant de chaînons manquants dans le monde ? Cela tient en partie simplement à un manque de prévoyance. Voici quelques raisons que vous pourriez entendre :

Nous venons de réorganiser le site pour le rendre meilleur.

Pensez-vous vraiment que les anciens URI ne peuvent plus fonctionner ? Si c’est le cas, alors vous les avez très mal choisis. Pensez à conserver les nouveaux pour la prochaine refonte.

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

Je ne peux que sympathiser. Le W3C a traversé une période où nous avons dû examiner soigneusement les documents d'archives pour en assurer la confidentialité avant de les rendre publics. La décision doit être réfléchie à l'avance - assurez-vous qu'avec chaque document, vous enregistrez le lectorat acceptable, la date de création et, idéalement, la date d'expiration. Enregistrez ces métadonnées.

Eh bien, nous avons découvert que nous devons déplacer des fichiers...

C’est l’une des excuses les plus pathétiques. Beaucoup de gens ne savent pas que les serveurs Web vous permettent de contrôler la relation entre l'URI d'un objet et son emplacement réel dans le système de fichiers. Considérez l’espace URI comme un espace abstrait, parfaitement organisé. Ensuite, faites une cartographie de la réalité que vous utilisez réellement pour la réaliser. Signalez-le ensuite au serveur Web. Vous pouvez même écrire votre propre extrait de serveur pour bien faire les choses.

John ne gère plus ce fichier, c'est désormais Jane qui le gère.

Le nom de John figurait-il dans l'URI ? Non, le fichier était-il uniquement dans son répertoire ? Bien, OK.

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

Il existe une idée folle selon laquelle les pages créées par des scripts devraient être situées dans la zone "cgibin" ou "cgi". Cela expose les mécanismes de la façon dont vous exécutez votre serveur Web. Vous modifiez le mécanisme (même lors de la sauvegarde du contenu), et oups, tous vos URI changent.

Prenez la National Science Foundation (NSF) par exemple :

Documents en ligne de la NSF

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

La première page permettant de visualiser les documents ne restera clairement pas la même dans quelques années. cgi-bin, oldbrowse и pl - tout cela donne des informations sur la façon dont nous le faisons maintenant. Si vous utilisez la page pour rechercher un document, le premier résultat que vous obtenez est tout aussi mauvais :

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, l'en-tête pubs/1998 donnera à tout futur service d'archives un bon indice que l'ancien système de classification des documents de 1998 est en vigueur. Bien que les numéros de documents puissent paraître différents en 2098, j'imagine que cet URI serait toujours valide et n'interférerait pas avec la NSF ou toute autre organisation qui maintiendrait les archives.

Je ne pensais pas que les URL devaient être persistantes : il existait des URN.

C’est probablement l’un des pires effets secondaires du débat sur l’URN. Certaines personnes pensent qu'en raison de la recherche sur un espace de noms plus permanent, elles pourraient ne pas se soucier des liens suspendus, car "les URN vont résoudre tout cela". Si vous faites partie de ces personnes, laissez-moi vous décevoir.

La plupart des schémas d'URN que j'ai vus ressemblent à un identifiant d'autorité suivi soit d'une date et d'une chaîne que vous sélectionnez, soit simplement d'une chaîne que vous sélectionnez. Ceci est très similaire à un URI HTTP. En d’autres termes, si vous pensez que votre organisation sera capable de créer des URN de longue durée, prouvez-le dès maintenant en les utilisant pour vos URI HTTP. Il n'y a rien dans HTTP lui-même qui rend votre URI instable. Uniquement votre organisation. Créez une base de données qui mappe l'URN du document au nom de fichier actuel et laissez le serveur Web l'utiliser pour récupérer les fichiers.

Si vous en êtes arrivé à ce point, si vous n’avez pas le temps, l’argent et les connexions nécessaires pour développer des logiciels, vous pouvez alors invoquer l’excuse suivante :

Nous le voulions, mais nous n’avons tout simplement pas les bons outils.

Mais vous pouvez sympathiser avec cela. Je suis complètement d'accord. Ce que vous devez faire est de forcer le serveur Web à analyser instantanément l'URI persistant et à renvoyer le fichier là où il est actuellement stocké sur votre système de fichiers fou actuel. Vous souhaitez stocker tous les URI dans un fichier à titre de contrôle et maintenir la base de données à jour à tout moment. Vous souhaitez préserver la relation entre les différentes versions et traductions du même document, et également conserver un enregistrement de somme de contrôle indépendant pour garantir que le fichier n'est pas corrompu par une erreur accidentelle. Et les serveurs Web ne sont tout simplement pas dotés de ces fonctionnalités. Lorsque vous souhaitez créer un nouveau document, votre éditeur vous demande de préciser un URI.

Vous devez pouvoir modifier la propriété, l'accès aux documents, la sécurité au niveau des archives, etc. dans l'espace URI sans modifier l'URI.

C'est vraiment dommage. Mais nous allons corriger la situation. Au W3C, nous utilisons la fonctionnalité Jigedit (serveur d'édition de puzzles) qui suit les versions et nous expérimentons des scripts de génération 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, pas ce que je fais.

Pourquoi devrais-je m'en soucier?

Lorsque vous modifiez l’URI sur votre serveur, vous ne pouvez jamais savoir exactement qui aura des liens vers l’ancien URI. Il peut s'agir de liens provenant de pages Web classiques. Ajoutez votre page à vos favoris. L'URI aurait pu être griffonné dans les marges d'une lettre adressée à un ami.

Lorsqu’une personne suit un lien et que celui-ci est rompu, elle perd généralement confiance dans le propriétaire du serveur. Il est également frustré, tant émotionnellement que physiquement, de ne pas pouvoir atteindre son objectif.

Beaucoup de gens se plaignent tout le temps des liens rompus, et j’espère que les dégâts sont évidents. J'espère que l'atteinte à la réputation du responsable du serveur sur lequel le document a disparu est également évidente.

Donc qu'est ce que je devrais faire? Conception d'URI

Il est de la responsabilité du webmaster d'attribuer des URI utilisables dans 2 ans, dans 20 ans, dans 200 ans. Cela demande réflexion, organisation et détermination.

Les URI changent si des informations qu'ils contiennent changent. La façon dont vous les concevez est très importante. (Quoi, la conception d'URI ? Dois-je concevoir l'URI ? Oui, vous devriez y penser). Concevoir signifie essentiellement omettre toute information dans l'URI.

La date de création du document – la date à laquelle l’URI a été émis – est quelque chose 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 système. C'est un bon point de départ avec un URI. Si un document est daté, même s’il sera pertinent dans le futur, alors c’est un bon début.

La seule exception est une page qui est intentionnellement la « dernière » version, par exemple pour l'ensemble ou une grande partie de l'organisation.

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

Ceci est la dernière chronique Money Daily du magazine Money. La principale raison pour laquelle il n'est pas nécessaire d'indiquer une date dans cet URI est qu'il n'y a aucune raison de stocker l'URI qui survivra au journal. Le concept de Money Daily disparaîtra lorsque Money disparaîtra. Si vous souhaitez créer un lien vers du contenu, vous devez créer un lien vers celui-ci séparément dans les archives :

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

(Ça a l'air bien. Suppose que "argent" signifiera la même chose tout au long de la vie de pathfinder.com. Il y a un "98" en double et un ".html" inutile, mais sinon cela ressemble à un URI fort.

Que laisser de côté

Tous! Hormis la date de création, mettre n'importe quelle information dans l'URI pose problème d'une manière ou d'une autre.

Nom de l'auteur. La paternité peut changer à mesure que de nouvelles versions sont disponibles. Les gens quittent les organisations et transmettent les choses aux autres.
Sujet. C'est très difficile. Cela semble toujours bien au début, mais change étonnamment vite. J'en parlerai davantage ci-dessous.
Statut. Des répertoires comme "old", "draft" et ainsi de suite, sans parler de "latest" et "cool", apparaissent dans tous les systèmes de fichiers. Les documents changent de statut - sinon il ne servirait à rien de créer des brouillons. La dernière version d'un document nécessite un identifiant persistant, quel que soit son statut. Gardez le statut en dehors du nom.
Accès. Au W3C, nous avons divisé le site en sections pour les employés, les membres et le public. Cela semble bien, mais bien sûr, les documents commencent comme des idées d'équipe émanant du personnel, sont discutés avec les membres, puis deviennent publics. Il serait vraiment dommage qu'à chaque fois qu'un document est ouvert à une discussion plus large, tous les anciens liens vers celui-ci soient rompus ! Passons maintenant à un simple code de date.
Extension de fichier. Un phénomène très courant. "cgi", même ".html" changera à l'avenir. Vous n'utiliserez peut-être plus le HTML pour cette page dans 20 ans, mais les liens actuels vers cette page devraient toujours fonctionner. Les liens canoniques sur le site du W3C n'utilisent pas l'extension (comment c'est fait).
Mécanismes logiciels. Dans l'URI, recherchez « cgi », « exec » et d'autres termes qui crient « regardez quel logiciel nous utilisons ». Quelqu'un souhaite-t-il passer toute sa vie à écrire des scripts Perl CGI ? Non? Supprimez ensuite l’extension .pl. Lisez le manuel du serveur pour savoir comment procéder.
Nom du disque. Allez! Mais j'ai vu ça.

Le meilleur exemple de notre site est donc simplement

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

... rapport sur le compte rendu de la réunion des présidents du W3C.

Thèmes et classement par thème

Je reviendrai plus en détail sur ce danger, car c'est l'une des choses les plus difficiles à éviter. En règle générale, les sujets se retrouvent dans les URI lorsque vous catégorisez vos documents en fonction du travail qu'ils effectuent. Mais cette répartition évoluera avec le temps. Les noms des zones vont changer. Au W3C, nous voulions changer MarkUP en Markup puis en HTML pour refléter le contenu réel de la section. De plus, il existe souvent un espace de noms plat. Dans 100 ans, êtes-vous sûr de ne plus vouloir rien réutiliser ? Dans notre courte vie nous avons déjà eu envie de réutiliser « Historique » et « Feuilles de style » par exemple.

C'est une manière tentante d'organiser un site Web, et une manière vraiment tentante d'organiser n'importe quoi, y compris l'ensemble du Web. Il s’agit d’une excellente solution à moyen terme, mais qui présente de sérieuses lacunes à long terme.

Une partie de la raison réside dans la philosophie du sens. Chaque terme d’une langue est une cible potentielle de regroupement, et chaque personne peut avoir une idée différente de ce que cela signifie. Étant donné que les relations entre les entités ressemblent davantage à un réseau qu’à un arbre, même ceux qui sont d’accord avec le réseau peuvent choisir une représentation différente de l’arbre. Ce sont mes observations générales (souvent répétées) sur les dangers de la classification hiérarchique en tant que solution générale.

En fait, lorsque vous utilisez un nom de sujet dans un URI, vous vous engagez dans une sorte de classification. Peut-être qu’à l’avenir vous préférerez une option différente. L’URI sera alors susceptible d’être violé.

La raison pour laquelle on utilise un domaine dans le cadre d'un URI est que la responsabilité des sous-sections de l'espace URI est généralement déléguée, et vous avez ensuite besoin du nom de l'organisme organisationnel - département, groupe ou autre - responsable de ce sous-espace. Il s'agit d'un URI lié à une structure organisationnelle. Ce n'est généralement sûr que si l'URI le plus à gauche est protégé par une date : 1998/pics peut signifier pour votre serveur "ce que nous voulions dire en 1998 avec des photos" plutôt que "ce que nous avons fait en 1998 avec ce que nous appelons maintenant des photos".

N'oubliez pas le nom de domaine

N'oubliez pas que cela s'applique non seulement au chemin dans l'URI, mais également au nom du serveur. Si vous disposez de serveurs séparés pour différentes choses, n'oubliez pas que cette division sera impossible à modifier sans détruire de très nombreux liens. Certaines erreurs classiques de type "regardez les logiciels que nous utilisons aujourd'hui" sont les noms de domaine "cgi.pathfinder.com", "secure", "lists.w3.org". Ils sont conçus pour faciliter l'administration du serveur. Qu'un domaine représente une division de votre entreprise, un statut de document, un niveau d'accès ou un 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 masquer plusieurs serveurs Web dans un seul serveur Web visible à l'aide de la redirection et du proxy.

Oh, et pensez aussi à votre nom de domaine. Vous ne voulez pas être appelé soap.com après avoir changé de gamme de produits et arrêté de fabriquer du savon (désolé pour celui qui possède Soap.com pour le moment).

Conclusion

Conserver une URI pendant 2, 20, 200, voire 2000 ans n’est évidemment pas aussi simple qu’il y paraît. Cependant, partout sur Internet, les webmasters prennent des décisions qui rendent cette tâche très difficile pour eux-mêmes à l'avenir. Cela est souvent dû au fait qu'ils utilisent des outils dont le travail est de présenter le meilleur site uniquement pour le moment - et personne n'a évalué ce qu'il adviendra des liens lorsque tout changera. Cependant, le point ici est que beaucoup de choses peuvent changer et que vos URI peuvent et doivent rester les mêmes. Cela n’est possible que lorsque vous réfléchissez à la manière dont vous les créez.

Voir aussi:

La tirade de Jakob Nielsen sur le même sujet

Additions

Comment supprimer les extensions de fichiers...

...à partir d'un URI dans le serveur Web actuel basé sur des fichiers ?

Si vous utilisez Apache, par exemple, vous pouvez le configurer pour négocier le contenu. Enregistrez l'extension du fichier (par exemple .png) dans un fichier (par ex. monchien.png), mais vous pouvez créer un lien vers une ressource Web sans cela. Apache vérifie ensuite dans le répertoire tous les fichiers portant ce nom et toute extension, et peut choisir le meilleur parmi l'ensemble (par exemple, GIF et PNG). Et il n'est pas nécessaire de placer différents types de fichiers dans différents répertoires, en fait, la correspondance de contenu ne fonctionnera pas si vous faites cela.

Configurez votre serveur pour négocier le contenu
Toujours créer un lien vers les URI sans extension

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

(En fait, mydog, mydog.png и mydog.gif — des ressources Web valides, mydog est une ressource de type de contenu universelle, et mydog.png и mydog.gif — ressources d'un type de contenu spécifique).

Bien sûr, si vous écrivez votre propre serveur Web, c'est une bonne idée d'utiliser une base de données pour lier les identifiants persistants à leur forme actuelle, mais méfiez-vous de la croissance illimitée de la base de données.

Le Conseil de la Honte - Histoire 1 : Channel 7

En 1999, j'ai suivi les fermetures d'écoles en raison de la neige sur la page http://www.whdh.com/stormforce/closings.shtml. N'attendez pas que l'information apparaisse en bas de l'écran du téléviseur ! J'y ai fait un lien depuis ma page d'accueil. La première grosse tempête de neige de 2000 arrive et je consulte la page. Il est écrit là :,

- À compter de.
Rien n'est fermé actuellement. Veuillez revenir en cas d'avertissements météorologiques.

Cela ne peut pas être une tempête aussi violente. C'est drôle qu'il manque la date. Mais si vous allez sur la page principale du site, il y aura un gros bouton « Écoles fermées », qui mènera à la page http://www.whdh.com/stormforce/ avec une longue liste d'écoles fermées.

Peut-être qu'ils ont changé le système d'obtention de la liste - mais ils n'ont pas eu besoin de changer l'URI.

Board of Shame - Histoire 2 : Microsoft Netmeeting

Avec la dépendance croissante à l’égard d’Internet, une idée astucieuse est née : des liens vers le site Web du fabricant pourraient être intégrés dans des applications. Cela a été beaucoup utilisé et abusé, mais vous ne pouvez pas modifier l'URL. L'autre jour, j'ai essayé un lien du client Microsoft Netmeeting 2/quelque chose dans le menu Aide/Microsoft sur le Web/Objets gratuits et j'ai reçu une erreur 404 - aucune réponse du serveur n'a été trouvée. Peut-être que c'est déjà réglé...

Note historique : à la fin du 20e siècle, au moment où cet article a été écrit, « cool » était une épithète d'approbation, en particulier parmi les jeunes, indiquant la mode, la qualité ou la pertinence. Dans l'urgence, le chemin URI a souvent été choisi pour sa « fraîcheur » plutôt que pour son utilité ou sa durabilité. Cet article est une tentative de rediriger l’énergie derrière la recherche du cool.

Source: habr.com

Les URI sympas ne changent pas