De auteur is sir Tim Berners-Lee, de uitvinder van URI, URL, HTTP, HTML en het World Wide Web, en de huidige directeur van het W3C. Het artikel is geschreven in 1998.

Welke URI kan als 'cool' worden beschouwd?
Een die niet verandert.
Hoe veranderen URI's?
URI's veranderen niet: mensen veranderen ze.

Ideaal gezien zouden mensen geen redenen moeten hebben om URI's te veranderen (of om documenten niet te onderhouden), maar in de praktijk zijn er miljoenen.

In theorie bezit de nominale eigenaar van de domeinruimte daadwerkelijk de domeinnaamruimte en dus alle URI's daarin. Behalve insolvabiliteit, staat niets de eigenaar van de domeinnaam in de weg om deze naam te behouden. En in theorie is de URI-ruimte onder jouw domeinnaam volledig onder jouw controle, zodat je deze zo stabiel kunt maken als je wilt. In wezen is de enige goede reden voor een document om van internet te verdwijnen dat het bedrijf dat de domeinnaam bezat, failliet is gegaan of zich de kosten van het serveronderhoud niet meer kan veroorloven. Waarom zijn er dan zo veel dode links op internet? Voor een deel is het gewoon een gebrek aan vooruitziendheid. Hier zijn enkele redenen die je kunt horen:

We hebben de website gewoon opnieuw georganiseerd om deze beter te maken.

Denk je echt dat oude URI's niet meer kunnen werken? Als dat zo is, heb je ze heel slecht gekozen. Denk na over hoe de nieuwe na de volgende redesign bewaard blijven.

We hebben zoveel materiaal dat we niet kunnen bijhouden wat verouderd, wat vertrouwelijk is en wat nog actueel is, en daarom dachten we dat het beter was om alles gewoon uit te schakelen.

Ik kan alleen maar medelijden hebben. W3C heeft een periode doorgemaakt waarin we zorgvuldig archiefmateriaal moesten screenen op vertrouwelijkheid voordat we het openbaar maakten. Het besluit moet van tevoren goed doordacht zijn — zorg ervoor dat je met elk document een acceptabel lezerspubliek, de datum van creatie en idealiter de vervaldatum vastlegt. Bewaar deze metadata.

Nou, we hebben ontdekt dat we de bestanden moeten verplaatsen…

Dit is een van de meest schrijnende rechtvaardigingen. Veel mensen weten niet dat webservers je in staat stellen om de verbinding tussen de URI van een object en de daadwerkelijke locatie ervan in het bestandssysteem te beheren. Stel je de URI-ruimte voor als een abstracte ruimte, perfect georganiseerd. Maak vervolgens een mapping naar de echte realiteit die je daadwerkelijk gebruikt om deze te implementeren. Geef dit vervolgens door aan de webserver. Je kunt zelfs een fragment van je server schrijven om alles correct te doen.

John ondersteunt dit bestand niet meer, nu doet Jane dat.

Stond de naam van John in de URI? Nee, het bestand lag gewoon in zijn directory? Dat is duidelijk.

Eerder gebruikten we hiervoor een CGI-script, en nu gebruiken we een binaire toepassing.

Er is een krankzinnige idee dat pagina's die door scripts zijn gemaakt, in de "cgibin" of "cgi" zone moeten worden geplaatst. Dit onthult het mechanisme van hoe je je webserver aanstuurt. Verander het mechanisme (zelfs als je de inhoud behoudt), en oeps — al je URI's veranderen.

Laten we bijvoorbeeld de Nationale Wetenschapsstichting (NSF) nemen:

Online documenten van NSF

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

De eerste pagina om documenten te bekijken zal over een paar jaar duidelijk niet hetzelfde blijven. cgi-bin, oldbrowse en pl — dit alles geeft fragmenten van informatie over hoe-we-het-nu-doen. Als je echter een pagina gebruikt om een document te zoeken, krijg je meteen ook een even slecht resultaat:

Rapport van de werkgroep cryptografie en coderingstheorie

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

voor de indexpagina van het document, hoewel het html-document zelf er veel beter uitziet:

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

Hier geeft de titel pubs/1998 elke toekomstige archiefdienst een goede sleutel om te begrijpen dat het oude classificatieschema van documenten uit 1998 nog werkt. Hoewel in 2098 de documentnummers er misschien anders uitzien, kan ik me voorstellen dat deze URI nog steeds geldig zal zijn, en het zal NSF of een andere organisatie die het archief ondersteunt, niet in de weg staan.

Ik dacht niet dat URL's permanent moesten zijn — er waren toch URN's.

Waarschijnlijk is dit een van de ergste bijwerkingen van de discussie over URN. Sommigen denken dat als gevolg van onderzoek naar een meer permanent naamruimte ze nonchalant kunnen omgaan met dode links, omdat "URN dat allemaal zal oplossen". Als je een van deze mensen bent, laat me je dan teleurstellen.

De meeste URN-schema's die ik heb gezien, zien eruit als een autoriteitsidentificator, gevolgd door een datum en een string die je kiest, of gewoon een string die je kiest. Dit lijkt heel veel op een HTTP-URI. Met andere woorden, als je denkt dat jouw organisatie in staat zal zijn om langdurige URN's te creëren, bewijs dat dan nu door ze te gebruiken voor je HTTP-URI's. In HTTP zelf is er niets dat je URI onbetrouwbaar maakt. Alleen jouw organisatie. Maak een database die de URN van het document koppelt aan de huidige bestandsnaam, en laat de webserver deze gebruiken voor het feitelijke ophalen van bestanden.

Als je dit punt hebt bereikt, en als je geen tijd, geld en connecties hebt om enige software te ontwikkelen, kun je de volgende rechtvaardiging geven:

We wilden het, maar we hebben gewoon niet de juiste tools.

Daar kun je mee medelijden hebben. Ik ben het er helemaal mee eens. Wat je moet doen, is de webserver in staat stellen om onmiddellijk een permanente URI te verwerken en het bestand terug te geven, waar het ook momenteel wordt opgeslagen in jouw huidige chaotische bestandssysteem. Je wilt alle URI's in een bestand opslaan als verificatie en de database voortdurend actueel houden. Je wilt de relaties tussen verschillende versies en vertalingen van hetzelfde document behouden, evenals een onafhankelijke controlewaarde opnemen om te zorgen voor bescherming tegen bestandscorruptie door een toevallige fout. En webservers worden gewoon niet standaard geleverd met deze functies. Wanneer je een nieuw document wilt maken, vraagt je editor om een URI in te voeren.

Je hebt de mogelijkheid nodig om eigendom, toegang tot het document, archiveringsbeveiligingsniveau en andere zaken in de URI-ruimte te wijzigen zonder de URI te wijzigen.

Het is allemaal te slecht. Maar we zullen het probleem oplossen. Bij W3C gebruiken we de functionaliteit van Jigedit (de Jigsaw-server voor editing), die versies bijhoudt, en we experimenteren met scripts voor documentcreatie. Als je tools, servers en clients ontwikkelt, let op dit probleem!

Deze rechtvaardiging geldt ook voor veel W3C-pagina's, inclusief deze: dus doe wat ik zeg, niet wat ik doe.

Waarom zou ik me daar druk om maken?

Wanneer u de URI op uw server wijzigt, kunt u nooit volledig zeggen wie er naar de oude URI zal linken. Dit kunnen links zijn van gewone webpagina's. Bladwijzers naar uw pagina. De URI kan op de marges van een brief aan een vriend zijn gekrabbeld.

Wanneer iemand op een link klikt en deze is verbroken, verliest diegene meestal het vertrouwen in de eigenaar van de server. Ze zijn ook teleurgesteld - zowel emotioneel als in werkelijkheid door de onmogelijkheid om hun doel te bereiken.

Veel mensen klagen voortdurend over gebroken links, en ik hoop dat de schade duidelijk is. Ik hoop ook dat de reputatieschade voor de onderhoudsman van de server, waar het document verdwenen is, ook duidelijk is.

Wat moet ik doen? Ontwerp een URI.

Het is de plicht van de webbeheerder om URI's te maken die over 2 jaar, over 20 jaar, over 200 jaar nog gebruikt kunnen worden. Hiervoor zijn doordachtheid, organisatie en doelgerichtheid nodig.

URI's veranderen als er iets aan de informatie verandert. Het is erg belangrijk hoe je ze ontwerpt. (Wat, een URI ontwerpen? Moet ik een URI ontwerpen? Ja, daar moet je over nadenken). Ontwerpen betekent in wezen dat er geen informatie in de URI hoort te staan.

De datum van creatie van het document - de datum waarop de URI wordt uitgegeven - is iets dat nooit zal veranderen. Het is zeer nuttig om verzoeken die het nieuwe systeem gebruiken te scheiden van diegene die het oude systeem gebruiken. Dit is een goed begin voor een URI. Als er een datum op het document staat, zelfs als het document in de toekomst actueel blijft, dan is dat een goed begin.

De enige uitzondering is een pagina die opzettelijk de 'laatste' versie is, bijvoorbeeld voor een hele organisatie of een groot deel ervan.

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

Dit is de laatste column van Money Daily in het tijdschrift Money. De belangrijkste reden waarom deze URI geen datum nodig heeft, is dat er geen redenen zijn om de URI te behouden die het tijdschrift zal overleven. Het begrip Money Daily zal verdwijnen wanneer Money verdwijnt. Als je naar de inhoud wilt verwijzen, moet je er apart naar verwijzen in archieven:

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

(Het ziet er goed uit. Veronderstelt dat "money" gedurende het hele bestaan van pathfinder.com hetzelfde zal betekenen. Er is duplicatie van "98" en onnodige ".html", maar verder lijkt het een sterke URI.

Wat aan de kant laten

Alles! Behalve de creatiedatum, door enige informatie in de URI te plaatsen, vraag je op de een of andere manier om problemen.

De naam van de auteur. Het auteurschap kan veranderen met nieuwe versies. Mensen verlaten organisaties en geven dingen aan anderen door.
Onderwerp. Het is erg moeilijk. Het ziet er altijd goed uit in het begin, maar verandert verrassend snel. Ik zal hier verder op ingaan.
Status. Catalogi zoals 'oud', 'concept' en zo verder, om nog maar te zwijgen van 'laatst' en 'cool', verschijnen in alle bestandssystemen. Documenten veranderen van status — anders zou het geen zin hebben om concepten te maken. De laatste versie van een document heeft een constante identificatie nodig, ongeacht de status. Houd de status buiten de naam.
Toegang. Bij W3C hebben we de site verdeeld in secties voor medewerkers, leden en het publiek. Dat klinkt goed, maar documenten beginnen natuurlijk als teamideeën van medewerkers, worden besproken met leden en zijn dan openbaar. Het is echt frustrerend als elke keer dat een document breder wordt besproken, alle oude links naar dat document kapot gaan! Nu gaan we over op een eenvoudige datumcode.
Bestandsextensie. Een veelvoorkomend verschijnsel. "cgi", zelfs ".html" zal in de toekomst veranderen. Misschien gebruik je over 20 jaar geen HTML meer voor deze pagina, maar de links van vandaag moeten nog steeds werken. De canonieke links op de W3C-website gebruiken geen extensie (hoe dit gebeurt).
Softwaremechanismen. Zoek in de URI naar "cgi", "exec" en andere termen die schreeuwen 'kijk eens, welke software we gebruiken'. Wil iemand zijn hele leven aan Perl CGI-scripts wijden? Nee? Verwijder dan de extensie .pl. Lees de serverhandleiding over hoe je dat doet.
Schijfnaam. Kom op! Maar dat heb ik gezien.

Dus het beste voorbeeld van onze site is gewoon

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

… het verslag van de vergadering van de voorzitters van W3C.

Onderwerpen en classificatie per onderwerp

Ik zal die gevaar verder uitleggen, aangezien dit een van die dingen is die het moeilijkst te vermijden zijn. Over het algemeen komen thema's in de URI terecht wanneer je je documenten classificeert op basis van het werk dat je doet. Maar deze indeling zal in de loop van de tijd veranderen. De namen van de gebieden zullen veranderen. Bij W3C wilden we MarkUP veranderen in Markup en vervolgens in HTML om de werkelijke inhoud van de sectie weer te geven. Bovendien is hier vaak sprake van een platte naamruimte. Over 100 jaar ben je er zeker van dat je niets opnieuw wilt gebruiken? In ons korte leven hebben we al willen hergebruiken wat we 'Geschiedenis' en 'Stijlen' noemen, bijvoorbeeld.

Het is een verleidelijk manier om een website te organiseren — en werkelijk een aantrekkelijke manier om iets te organiseren, inclusief het hele web. Het is een geweldige middellange termijn oplossing, maar heeft ernstige nadelen op de lange termijn.

De oorzaken liggen gedeeltelijk in de filosofie van betekenis. Elke term in de taal is een potentieel clusteringobject, en elke persoon kan een verschillende interpretatie hebben van wat het betekent. Aangezien de relaties tussen onderwerpen meer op een web lijken dan op een boom, kunnen zelfs zij die het eens zijn met het web ervoor kiezen om een andere boomstructuur te gebruiken. Dit zijn mijn (vaak herhaalde) algemene opmerkingen over de gevaren van hiërarchische classificatie als algemene oplossing.

Eigenlijk, wanneer je de naam van een onderwerp in de URI gebruikt, verbind je jezelf aan een bepaalde classificatie. Misschien geef je in de toekomst de voorkeur aan een andere optie. Dan zal de URI kwetsbaar zijn voor schending.

De reden om het onderwerp als onderdeel van de URI te gebruiken, is dat de verantwoordelijkheid voor secties van de URI-ruimte meestal wordt gedelegeerd, en dan heb je de naam van de organisatorische instantie nodig — afdeling, groep of iets anders dat verantwoordelijk is voor deze subruimte. Dit verbindt de URI aan de organisatorische structuur. Dit is meestal alleen veilig als verder (links) in de URI de datum is beschermd: 1998/pics kan voor je server betekenen 'wat we in 1998 bedoelden met pics', en niet 'wat we in 1998 deden met wat we nu pics noemen'.

Vergeet de domeinnaam niet

Vergeet niet dat dit niet alleen betrekking heeft op het pad in de URI, maar ook op de servernaam. Als u aparte servers voor verschillende doeleinden heeft, moet u zich realiseren dat deze scheiding niet kan worden gewijzigd zonder veel links te verbreken. Sommige klassieke fouten zoals "kijk eens naar de software die we vandaag gebruiken" – domeinnamen "cgi.pathfinder.com", "secure", "lists.w3.org". Deze zijn ontworpen om het beheer van servers te vergemakkelijken. Ongeacht of het domein een bepaalde afdeling binnen uw bedrijf vertegenwoordigt, de status van het document, het toegangsniveau of het beveiligingsniveau, wees heel, heel voorzichtig voordat u meer dan één domeinnaam voor meerdere soorten documenten gebruikt. Vergeet niet dat u meerdere webservers kunt verbergen achter één zichtbare webserver door gebruik te maken van doorverwijzing en proxying.

Ja, en denk ook na over uw domeinnaam. U wilt niet dat mensen naar u verwijzen als zijnde soap.com nadat u uw productlijn hebt gewijzigd en geen zeep meer produceert (verontschuldigingen aan degene die momenteel soap.com bezit).

Conclusie

Het behouden van een URI voor 2, 20, 200 of zelfs 2000 jaar is duidelijk niet zo eenvoudig als het lijkt. Toch nemen webmasters op het internet beslissingen die het voor hen moeilijk maken deze taak in de toekomst te vervullen. Vaak gebeurt dit omdat ze tools gebruiken die zijn ontworpen om alleen de beste site op dat moment weer te geven – en niemand heeft nagedacht over wat er met de links zal gebeuren wanneer alles verandert. Het punt hier is dat veel, heel veel kan veranderen, en uw URI's moeten hetzelfde blijven. Dit is alleen mogelijk als u nadenkt over hoe u ze aanmaakt.

Zie ook:

De tirade van Jakob Nielsen over hetzelfde onderwerp

Extensies

Hoe bestandsuitbreidingen te verwijderen...

...uit de URI op de huidige webserver op basis van bestanden?

Als u bijvoorbeeld Apache gebruikt, kunt u het configureren om inhoud overeen te laten komen. U behoudt de bestandsuitbreiding (bijvoorbeeld .png) in het bestand (bijvoorbeeld, mydog.png), maar je kunt ook naar een webbron verwijzen zonder deze. Vervolgens controleert Apache de map op de aanwezigheid van alle bestanden met deze naam en om het even welke extensie, en kan het ook de beste uit een set kiezen (bijvoorbeeld GIF en PNG). En je hoeft verschillende bestandstypen niet in verschillende mappen te plaatsen; inhoudsafstemming werkt eigenlijk niet als je dat doet.

Configureer je server voor inhoudsafstemming
Link altijd naar URI's zonder extensie

Links met extensies werken nog steeds, maar stellen je server niet in staat de beste beschikbare en toekomstige indelingen te kiezen.

(Eigenlijk, mydog, mydog.png en mydog.gif — geldige webbronnen, mydog — dat is een bron van universele inhoudstype, terwijl mydog.png en mydog.gif — bronnen van specifiek inhoudstype zijn).

Natuurlijk, als je je eigen webserver schrijft, is het goed om een database te gebruiken voor het koppelen van permanente identificatoren aan hun huidige vorm, hoewel je moet oppassen voor onbeheersbare databasegroei.

Schande: Verhaal 1: Channel 7

Gedurende 1999 volgde ik het sluiten van scholen door sneeuw op de pagina http://www.whdh.com/stormforce/closings.shtml. Je gaat toch niet wachten tot de informatie onderaan het televisiescherm verschijnt! Ik zette een link erop vanaf mijn homepage. De eerste grote sneeuwstorm van 2000 komt, en ik controleer de pagina. Er staat:

— Op dit moment.
Er zijn momenteel geen sluitingen. Kom alsjeblieft terug in geval van weerswaarschuwingen.

Dat kan niet, zo'n sterke storm. Het is grappig dat de datum ontbreekt. Maar als je naar de hoofdpagina van de site gaat, is er een grote knop 'Gesloten scholen' die naar de pagina leidt http://www.whdh.com/stormforce/ met een lange lijst van gesloten scholen.

Misschien hebben ze het systeem voor het verkrijgen van de lijst veranderd — maar ze hoefden de URI niet te veranderen.

Schande: Verhaal 2: Microsoft Netmeeting

Met de groeiende afhankelijkheid van het internet kwam het slimme idee om links naar de website van de fabrikant in applicaties in te voegen. Dit werd vaak gebruikt en misbruikt, maar — je mag de URL niet veranderen. Onlangs probeerde ik een link uit de Microsoft Netmeeting 2/something-client in het menu Help/Microsoft on the Web/Free stuff en kreeg een 404-fout — de server antwoordde niet. Misschien is het al opgelost…

Historische opmerking: aan het einde van de 20e eeuw, toen dit geschreven werd, was 'cool' een goedkeurend epitheton, vooral onder jongeren, dat duidde op trendy, kwaliteit of relevantie. In de haast werd de URI vaak gekozen op basis van 'coolheid' in plaats van bruikbaarheid of duurzaamheid. Deze opmerking is een poging om de energie die achter de zoektocht naar coolheid staat om te zetten.

Bron: habr.com