Les URI sympas ne changent pas

Par Sir Tim Berners-Lee, inventeur des URI, des URL, du HTTP, du HTML et du World Wide Web, actuel responsable du W3C. Écrit en 1998



Quel URI est cool?

Celui qui ne change pas.

Comment les URI changent-ils?

Les URI ne changent pas: les gens les changent.



En théorie, il n'y a aucune raison pour que les humains modifient les URI (ou arrêtent de maintenir des documents), mais en pratique, il y en a des millions.



En théorie, le propriétaire nominal de l'espace de noms de domaine est en fait propriétaire de l'espace de noms de domaine et donc de 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 cessé ses activités ou ne peut plus se permettre de maintenir le serveur en marche. Alors pourquoi y a-t-il tant de chaînons manquants dans le monde? C'est en partie juste un manque de prévoyance. Voici quelques-unes des raisons que vous pouvez entendre:



Nous venons de réorganiser le site pour l'améliorer.



Avez-vous vraiment l'impression que les anciens URI ne peuvent plus fonctionner? Si oui, vous les avez très mal choisis. Pensez à garder les nouveaux de la prochaine refonte.



Nous avons tellement de matériel que nous ne pouvons pas garder une trace de ce qui est désuet, de ce qui est confidentiel et de ce qui est toujours pertinent, et nous avons donc pensé qu'il valait mieux simplement le désactiver.



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



Eh bien, nous avons constaté que nous devions déplacer les 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. Pensez à un espace URI comme un espace abstrait, parfaitement organisé. Ensuite, mappez sur la réalité que vous utilisez réellement pour l'implémenter. Ensuite, signalez-le au serveur Web. Vous pouvez même écrire un extrait de votre serveur pour bien faire les choses.



John ne gère plus ce fichier, maintenant Jane.



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



Nous avions l'habitude d'utiliser un script CGI pour cela, mais maintenant nous utilisons un programme binaire.



Il y a une idée folle que les pages scriptées devraient être situées dans la zone "cgibin" ou "cgi". Cela expose le mécanisme de démarrage de votre serveur Web. Changez le mécanisme (même en gardant le contenu) et oups - tous vos URI changent.



Prenons l'exemple de la National Science Foundation (NSF): NSF



Online Documents

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


La première page pour commencer à consulter les documents ne restera clairement plus la même dans quelques années. cgi-bin, oldbrowseet pl - tout cela donne des particules d'informations sur comment-nous-faisons-maintenant. Si vous utilisez la page pour rechercher un document, vous obtenez d'abord un résultat 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 beaucoup mieux:



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


Ici, la rubrique pubs / 1998 donnera à tout service d'archivage futur un bon indice que l'ancien système de classification des documents de 1998 est en vigueur. Bien que les numéros de document puissent sembler différents en 2098, je peux imaginer que cet URI sera toujours valide et n'interférera pas avec la NSF ou toute autre organisation qui maintiendra l'archive de quelque manière que ce soit.



Je ne pensais pas que les URL étaient censées être persistantes - c'étaient des URN.



C'est probablement l'un des pires effets secondaires de la discussion URN. Certaines personnes pensent qu'en raison de recherches sur un espace de noms plus persistant, elles peuvent être négligentes à propos des liens suspendus parce que "les URN vont tout réparer." Si vous faites partie de ces personnes, laissez-nous être déçus.



La plupart des schémas URN que j'ai vus ressemblent à un identifiant d'autorité suivi de la date et de la chaîne que vous sélectionnez ou simplement de la chaîne que vous sélectionnez. Ceci est très similaire à l'URI HTTP. En d'autres termes, si vous pensez que votre organisation sera en mesure de créer des URN de longue durée, prouvez-le maintenant en les utilisant pour vos URI HTTP. Il n'y a rien dans HTTP lui-même qui rend votre URI instable. Seulement 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, alors si vous n'avez pas le temps, l'argent et les connexions pour développer un type de logiciel, vous pouvez indiquer l'excuse suivante:



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



Mais vous pouvez sympathiser avec cela. Je suis entièrement d'accord. Ce que vous devez faire est de forcer le serveur Web à traiter instantanément l'URI persistant et à renvoyer le fichier là où il est actuellement stocké dans votre système de fichiers fou actuel. Vous souhaitez conserver tous les URI dans un fichier à titre de vérification 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 vous protéger contre les erreurs accidentelles dans le fichier. Et les serveurs Web ne sont tout simplement pas prêts à l'emploi avec ces fonctionnalités. Lorsque vous souhaitez créer un nouveau document, votre éditeur vous demande un URI.



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



C'est dommage. Mais nous allons régler la situation. Au W3C, nous utilisons la fonctionnalité Jigedit (un serveur d'édition Jigsaw) qui assure le suivi des versions, et nous expérimentons 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, pas ce que je fais.



Pourquoi devrais-je m'en soucier?



Lorsque vous modifiez l'URI sur votre serveur, vous ne pouvez jamais dire complètement qui référencera l'ancien URI. Il peut s'agir de liens provenant de pages Web régulières. Marque-pages sur votre page. L'URI peut avoir été rayé dans la marge d'une lettre à un ami.



Quand quelqu'un clique sur un lien et qu'il est cassé, il perd généralement confiance dans le propriétaire du serveur. Il est également déçu - à la fois émotionnellement et de manière réaliste par son incapacité à atteindre son objectif.



Beaucoup de gens se plaignent constamment de liens rompus et j'espère que les dégâts sont évidents. J'espère que l'atteinte à la réputation du mainteneur du serveur où 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 en 2 ans, en 20 ans, en 200 ans. Cela nécessite de la réflexion, de l'organisation et de l'engagement.



Les URI changent si certaines informations changent. La façon dont vous les concevez est très importante. (Quoi, conception d'URI? J'ai besoin de concevoir un URI? Oui, vous devriez y réfléchir). La conception signifie essentiellement ne pas avoir d'informations dans l'URI.



La date à laquelle le document a été créé - la date à laquelle l'URI a été émis - quelque chose qui ne changera jamais. Il est très utile pour séparer les demandes qui utilisent le nouveau système de celles qui utilisent l'ancien système. C'est un bon point de départ pour un URI. Si le document est daté, même si le document est pertinent dans le futur, c'est un bon début.



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



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


Ceci est la dernière chronique de Money Daily dans le magazine Money. La raison principale pour laquelle cet URI n'a pas besoin de date est qu'il n'y a aucune raison de stocker un 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» signifie la même chose pour la vie de pathfinder.com. Il y a «98» en double et «.html» inutile, mais autrement ressemble à un URI fort.



Que laisser de côté



Tout! Mis à part la date de création, mettre des informations dans un URI est d'une manière ou d'une autre un problème.



  • Nom de l'auteur . Le blâme peut changer avec les nouvelles versions. Les gens quittent les organisations et transmettent des choses aux autres.

  • Sujet . C'est très difficile. Il a toujours l'air bien au début, mais change étonnamment rapidement. Je vais entrer plus en détail ci-dessous.

  • Statut . Des répertoires tels que «ancien», «brouillon», etc., sans oublier «dernier» et «cool», apparaissent sur tous les systèmes de fichiers. Les documents changent de statut - sinon, il serait inutile de créer des brouillons. La dernière version d'un document nécessite un identifiant persistant, quel que soit son état. Gardez le statut hors du nom.

  • . W3C , . , , , , , . , , , - , ! .

  • . . "cgi", ".html" . , 20 HTML , . W3C ( ).

  • Mécanismes logiciels . Dans l'URI, recherchez «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? Supprimez ensuite l'extension .pl. Lisez le manuel du serveur pour savoir comment procéder.

  • Nom du disque. Allons! Mais j'ai vu ça.


Le meilleur exemple de notre site est donc tout simplement



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


… Un rapport du procès-verbal de la réunion des présidents du W3C.



Thèmes et classification par thème



Je vais entrer 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 rubriques se retrouvent dans des URI lorsque vous catégorisez vos documents par travail en cours. Mais cette répartition changera avec le temps. Les noms de zone changeront. Au W3C, nous voulions changer MarkUP en Markup puis HTML pour refléter le contenu réel de la section. De plus, l'espace de noms est souvent plat. Après 100 ans, êtes-vous sûr de ne plus vouloir réutiliser quoi que ce soit? Dans notre courte vie, nous voulions déjà réutiliser "History" et "Style Sheets", par exemple.



C'est une façon tentante d'organiser un site Web - et une façon vraiment tentante d'organiser n'importe quoi, y compris l'ensemble du Web. C'est une excellente solution à moyen terme, mais elle présente de sérieux inconvénients à long terme.



Une partie de la raison réside dans la philosophie du sens. Chaque terme de la langue est un objet de regroupement potentiel, et chaque personne peut avoir une idée différente de ce que cela signifie. Comme la relation entre les sujets ressemble plus à une toile d'araignée qu'à un arbre, même ceux qui sont d'accord avec la toile d'araignée peuvent choisir une représentation différente de l'arbre. Ce sont mes remarques générales (souvent répétées) sur les dangers de la classification hiérarchique comme solution générale.



En fait, lorsque vous utilisez un nom de rubrique dans un URI, vous vous associez à une sorte de classification. Vous pouvez choisir une autre option à l'avenir. Ensuite, l'URI sera sujet à violation.



La raison de l'utilisation d'un domaine dans le cadre d'un URI est que la responsabilité des sous-sections d'un espace URI est généralement déléguée, auquel cas vous avez besoin du nom de l'organe organisationnel - une unité, un groupe ou tout autre élément responsable de ce sous-espace. Il s'agit de la liaison de l'URI à la structure organisationnelle. Il n'est généralement sûr que lorsque l'URI plus bas (à gauche) est protégé par une date: 1998 / pics pourrait signifier pour votre serveur «ce que nous entendions en 1998 par pics», et non «ce que nous avons fait avec 1998 ce que nous appelons maintenant des photos. "



N'oubliez pas votre 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 avez des serveurs séparés pour différentes choses, rappelez-vous que cette séparation ne sera pas possible de changer sans détruire de très nombreux liens. Certaines erreurs classiques comme «regardez quel logiciel 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. Que le domaine représente un service spécifique au sein de votre entreprise, l'état du document, le niveau d'accès ou le niveau de sécurité, soyez très, très prudent avant d'utiliser plusieurs noms de domaine pour plusieurs types de documents. N'oubliez pas que vous pouvez masquer de nombreux serveurs Web dans un serveur Web visible,en utilisant la redirection et le proxy.



Oui, et pensez également à votre nom de domaine. Vous ne voulez pas être appelé soap.com après avoir changé votre gamme de produits et arrêté de fabriquer du savon (désolé pour le propriétaire de soap.com pour le moment).



Conclusion



Sauvegarder un URI pendant 2, 20, 200 ou même 2000 ans n'est évidemment pas aussi simple qu'il y paraît. Cependant, partout sur Internet, les webmasters prennent des décisions qui rendront la tâche difficile pour eux-mêmes à l'avenir. C'est souvent parce qu'ils utilisent des outils dont le travail est de présenter le meilleur site uniquement pour le moment - et personne n'a estimé ce qu'il adviendra des liens lorsque tout changera. Cependant, le fait est que beaucoup, beaucoup de choses peuvent changer et que vos URI peuvent et doivent rester les mêmes. Cela n'est possible que lorsque vous pensez à la façon dont vous les créez.



Voir également:



Suppléments



Comment supprimer les extensions de fichier ...



... à 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. Vous enregistrez l'extension de fichier (par exemple, .png) dans un fichier (par exemple, mydog.png ), mais vous pouvez créer un lien vers une ressource Web sans elle. Apache vérifie ensuite le répertoire pour tous les fichiers avec ce nom et n'importe quelle extension, et peut choisir le meilleur de 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 négociation de contenu ne fonctionnera pas si vous le faites.



  • Configurez votre serveur pour négocier le contenu

  • Toujours référencer les URI sans extension


Les liens d'extension fonctionneront toujours, mais empêcheront votre serveur de choisir le meilleur format actuellement disponible et à l'avenir.



(En fait, mydog, mydog.pnget mydog.gif- codes et ressources web mydog- un type de contenu de ressource universelle, mydog.pnget mydog.gif- les ressources d'un contenu de type particulier).



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.



Tableau de la honte - Histoire 1: Channel 7



En 1999, j'ai suivi les fermetures d'écoles dues à la neige sur une page http://www.whdh.com/stormforce/closings.shtml. N'attendez pas que les informations apparaissent en bas de l'écran du téléviseur! Je l'ai lié depuis ma page d'accueil. La première grosse tempête de neige de 2000 arrive et je regarde la page. Il dit:



- À partir de.

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




Ce ne peut pas être la même forte tempête. C'est drôle que la date manque. Mais si vous allez sur la page principale 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 qu'ils ont changé le système pour obtenir la liste - mais ils n'ont pas eu besoin de changer l'URI.



Conseil de la honte - Histoire 2: Microsoft Netmeeting



Avec la dépendance croissante à Internet, l'idée intelligente est venue de proposer des applications permettant d'intégrer des liens vers le site Web du fabricant. Cela a été beaucoup utilisé et abusé, mais - vous ne pouvez pas changer 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 / Trucs gratuits et j'ai obtenu une erreur 404 - aucune réponse trouvée du serveur. Peut-être déjà fixé ...



© 1998 Tim BL



Note historique: À la fin du 20e siècle, quand cela a été écrit, «cool» était une épithète d'approbation, en particulier chez les jeunes, indiquant la mode, la qualité ou la pertinence. À la hâte, le chemin URI était souvent choisi par rapport à «cool» plutôt qu'à l'utilité ou à la longévité. Cet article est une tentative de rediriger l'énergie derrière la quête du cool.



Voir également:






All Articles