Auteur: Sir Tim Berners-Lee, uitvinder van URI's, URL's, HTTP, HTML en het World Wide Web, en huidig hoofd van het W3C. Artikel geschreven in 1998

Welke URI wordt als 'cool' beschouwd?
Eén die niet verandert.
Hoe veranderen URI's?
URI's veranderen niet: mensen veranderen ze.

In theorie is er geen reden voor mensen om URI’s te veranderen (of te stoppen met ondersteunende documenten), maar in de praktijk zijn het er miljoenen.

In theorie is de nominale eigenaar van een domeinnaamruimte feitelijk eigenaar van de domeinnaamruimte en dus van alle URI's daarin. Behalve insolventie belet niets de eigenaar van een domeinnaam om de naam te behouden. En in theorie heeft u de URI-ruimte onder uw domeinnaam volledig onder uw controle, dus u kunt deze zo stabiel maken als u wilt. Vrijwel de enige goede reden voor het verdwijnen van een document van internet is dat het bedrijf dat eigenaar was van de domeinnaam failliet is gegaan of het zich niet langer kan veroorloven om de server draaiende te houden. Waarom zijn er dan zoveel ontbrekende schakels in de wereld? Een deel hiervan is eenvoudigweg een gebrek aan voorzorg. Hier zijn enkele redenen die u mogelijk te horen krijgt:

We hebben zojuist de site gereorganiseerd om deze nog beter te maken.

Denk je echt dat de oude URI's niet meer kunnen werken? Als dat zo is, dan heb je ze heel slecht gekozen. Overweeg om de nieuwe te behouden voor het volgende herontwerp.

We hebben zoveel dingen dat we niet kunnen bijhouden wat verouderd is, wat vertrouwelijk is en wat nog steeds relevant is, dus we dachten dat het het beste was om het allemaal uit te zetten.

Ik kan alleen maar sympathiseren. W3C maakte een periode door waarin we zorgvuldig archiefmateriaal moesten doorzoeken op vertrouwelijkheid voordat we het openbaar maakten. Over de beslissing moet van tevoren worden nagedacht: zorg ervoor dat u bij elk document het aanvaardbare lezerspubliek, de aanmaakdatum en, idealiter, de vervaldatum vastlegt. Bewaar deze metagegevens.

We hebben ontdekt dat we bestanden moeten verplaatsen...

Dit is een van de meest zielige excuses. Veel mensen weten niet dat u met webservers de relatie tussen de URI van een object en de daadwerkelijke locatie in het bestandssysteem kunt controleren. Beschouw de URI-ruimte als een abstracte ruimte, perfect georganiseerd. Maak vervolgens een mapping naar welke realiteit je ook daadwerkelijk gebruikt om het te realiseren. Meld dit dan aan de webserver. U kunt zelfs uw eigen serverfragment schrijven om het goed te doen.

John onderhoudt dit bestand niet langer, Jane doet dat nu.

Stond de naam van John in de URI? Nee, stond het bestand alleen in zijn map? Nou, oké.

Voorheen gebruikten we hiervoor een CGI-script, maar nu gebruiken we een binair programma.

Er is een gek idee dat pagina's die door scripts zijn gemaakt, zich in het "cgibin"- of "cgi"-gebied zouden moeten bevinden. Dit legt de werking bloot van hoe u uw webserver beheert. Je verandert het mechanisme (zelfs terwijl je inhoud opslaat), en oeps: al je URI's veranderen.

Neem bijvoorbeeld de National Science Foundation (NSF):

NSF online-documenten

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

De eerste pagina waarop u documenten gaat bekijken, zal over een paar jaar duidelijk niet meer hetzelfde zijn. cgi-bin, oldbrowse и pl - dit alles geeft stukjes informatie over hoe-we-het-nu-doen. Als u de pagina gebruikt om naar een document te zoeken, is het eerste resultaat dat u krijgt even slecht:

Verslag van de Werkgroep Cryptologie en Coderingstheorie

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

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

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

Hier zal de kop pubs/1998 elke toekomstige archiefdienst een goede aanwijzing geven dat het oude documentclassificatieschema uit 1998 van kracht is. Hoewel de documentnummers er in 2098 misschien anders uitzien, kan ik me voorstellen dat deze URI nog steeds geldig zou zijn en zich niet zou bemoeien met NSF of enige andere organisatie die het archief zou onderhouden.

Ik dacht niet dat URL's persistent moesten zijn; er waren URN's.

Dit is waarschijnlijk een van de ergste bijwerkingen van het URN-debat. Sommige mensen denken dat ze vanwege het onderzoek naar een meer permanente naamruimte onzorgvuldig zullen zijn met bungelende links, omdat "URN's dat allemaal zullen oplossen." Als u een van deze mensen bent, laat mij u dan teleurstellen.

De meeste URN-schema's die ik heb gezien, zien eruit als een autoriteitsidentificatie, gevolgd door een datum en een tekenreeks die u selecteert, of gewoon een tekenreeks die u selecteert. Dit lijkt sterk op een HTTP-URI. Met andere woorden: als u denkt dat uw organisatie in staat zal zijn om URN's met een lange levensduur te maken, bewijs dat dan nu door ze te gebruiken voor uw HTTP-URI's. Er is niets in HTTP zelf dat uw URI onstabiel maakt. Alleen uw organisatie. Creëer een database die het document URN toewijst aan de huidige bestandsnaam, en laat de webserver deze gebruiken om de bestanden daadwerkelijk op te halen.

Als je dit punt hebt bereikt, als je niet de tijd, het geld en de connecties hebt om software te ontwikkelen, dan kun je het volgende excuus gebruiken:

Dat wilden we wel, maar we hebben gewoon niet het juiste gereedschap.

Maar je kunt er wel mee sympathiseren. Ik ben het er helemaal mee eens. Wat u moet doen is de webserver dwingen om onmiddellijk de persistente URI te parseren en het bestand terug te sturen waar het momenteel is opgeslagen op uw huidige gekke bestandssysteem. U wilt ter controle alle URI's in een bestand opslaan en de database altijd up-to-date houden. U wilt de relatie tussen verschillende versies en vertalingen van hetzelfde document behouden, en ook een onafhankelijk controlesomrecord bijhouden om ervoor te zorgen dat het bestand niet beschadigd raakt door een onbedoelde fout. En webservers komen eenvoudigweg niet uit de doos met deze functies. Wanneer u een nieuw document wilt maken, vraagt uw redacteur u om een URI op te geven.

U moet in de URI-ruimte het eigendom, de documenttoegang, de beveiliging op archiefniveau, enz. kunnen wijzigen zonder de URI te wijzigen.

Het is allemaal jammer. Maar we zullen de situatie corrigeren. Bij W3C gebruiken we de Jigedit-functionaliteit (Jigsaw editing server) die versies bijhoudt, en experimenteren we met scripts voor het genereren van documenten. Als u tools, servers en clients ontwikkelt, let dan op dit probleem!

Dit excuus geldt ook voor veel W3C-pagina's, waaronder deze: doe wat ik zeg, niet zoals ik.

Waarom zou ik erom geven?

Wanneer u de URI op uw server wijzigt, kunt u nooit volledig zeggen wie links naar de oude URI heeft. Dit kunnen links zijn vanaf gewone webpagina's. Maak een bladwijzer van uw pagina. De URI zou in de marge van een brief aan een vriend gekrabbeld kunnen zijn.

Wanneer iemand een link volgt en deze wordt verbroken, verliest hij meestal het vertrouwen in de servereigenaar. Hij is ook gefrustreerd, zowel emotioneel als fysiek, omdat hij zijn doel niet kan bereiken.

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

Dus wat moet ik doen? URI-ontwerp

Het is de verantwoordelijkheid van de webmaster om URI's toe te wijzen die over 2 jaar, over 20 jaar, over 200 jaar gebruikt kunnen worden. Dit vereist bedachtzaamheid, organisatie en vastberadenheid.

URI's veranderen als de informatie daarin verandert. Hoe je ze ontwerpt, is erg belangrijk. (Wat, URI-ontwerp? Moet ik de URI ontwerpen? Ja, daar moet je over nadenken). Ontwerp betekent in feite het weglaten van alle informatie in de URI.

De datum waarop het document is gemaakt (de datum waarop de URI is uitgegeven) is iets dat nooit zal veranderen. Het is erg handig om zoekopdrachten die het nieuwe systeem gebruiken te scheiden van zoekopdrachten die het oude systeem gebruiken. Dit is een goede plek om te beginnen met een URI. Als een document gedateerd is, zelfs als het document in de toekomst relevant zal zijn, dan is dit een goed begin.

De enige uitzondering is een pagina die bewust de ‘nieuwste’ versie is, bijvoorbeeld voor de hele organisatie of een groot deel ervan.

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

Dit is de nieuwste Money Daily-column in Money magazine. De belangrijkste reden dat er geen datum in deze URI nodig is, is dat er geen reden is om de URI op te slaan die het logboek zal overleven. Het concept van Money Daily zal verdwijnen als Money verdwijnt. Als u naar inhoud wilt linken, moet u hier afzonderlijk naar linken in de archieven:

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

(Ziet er goed uit. Er wordt van uitgegaan dat "geld" hetzelfde zal betekenen gedurende de hele levensduur van pathfinder.com. Er is een dubbele "98" en een onnodige ".html", maar ziet er verder uit als een sterke URI.

Wat terzijde te laten

Alle! Afgezien van de aanmaakdatum is het plaatsen van informatie in de URI op de een of andere manier vragen om problemen.

Auteursnaam. Het auteurschap kan veranderen naarmate er nieuwe versies beschikbaar komen. Mensen verlaten organisaties en geven dingen door aan anderen.
subject. Het is heel moeilijk. Het ziet er in eerste instantie altijd goed uit, maar verandert verrassend snel. Ik zal hier hieronder meer over vertellen.
Staat. Mappen zoals "oud", "concept" enzovoort, en niet te vergeten "nieuwste" en "cool", verschijnen in alle bestandssystemen. Documenten veranderen van status - anders heeft het geen zin om concepten te maken. De nieuwste versie van een document heeft een persistente identificatie nodig, ongeacht de status ervan. Houd de status uit de naam.
Toegang. Bij W3C hebben we de site opgedeeld in secties voor medewerkers, leden en het publiek. Dit klinkt goed, maar documenten beginnen uiteraard als teamideeën van het personeel, worden met de leden besproken en worden vervolgens algemeen bekend. Het zou echt zonde zijn als elke keer dat een document wordt geopend voor bredere discussie, alle oude links ernaar worden verbroken! Nu gaan we verder met een eenvoudige datumcode.
Bestandsextensie. Een veel voorkomend verschijnsel. "cgi", zelfs ".html" zal in de toekomst veranderen. Mogelijk gebruikt u over twintig jaar geen HTML meer voor deze pagina, maar de huidige links ernaar zouden nog steeds moeten werken. Canonieke links op de W20C-site gebruiken de extensie (hoe het gedaan wordt).
Softwaremechanismen. Zoek in de URI naar 'cgi', 'exec' en andere termen die schreeuwen 'kijk eens welke software we gebruiken'. Wil iemand zijn hele leven besteden aan het schrijven van Perl CGI-scripts? Nee? Verwijder vervolgens de .pl-extensie. Lees de serverhandleiding hoe u dit doet.
Schijfnaam. Kom op! Maar ik heb dit gezien.

Het beste voorbeeld van onze site is dus simpelweg

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

... verslag uitbrengen over de notulen van de W3C-voorzittersvergadering.

Onderwerpen en classificatie per onderwerp

Ik zal dieper op dit gevaar ingaan, omdat het een van de dingen is die het moeilijkst te vermijden zijn. Meestal komen onderwerpen terecht in URI's wanneer u uw documenten categoriseert op basis van het werk dat ze doen. Maar deze verdeling 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 daadwerkelijke inhoud van de sectie weer te geven. Daarnaast is er vaak sprake van een platte naamruimte. Weet u zeker dat u over 100 jaar niets meer wilt hergebruiken? In ons korte leven wilden we bijvoorbeeld al ‘Geschiedenis’ en ‘Style Sheets’ hergebruiken.

Het is een verleidelijke manier om een website te organiseren, en een werkelijk verleidelijke manier om alles te organiseren, inclusief het hele internet. Dit is een geweldige oplossing voor de middellange termijn, maar kent op de lange termijn ernstige tekortkomingen.

Een deel van de reden ligt in de filosofie van betekenis. Elke term in een taal is een potentieel doelwit voor clustering, en elke persoon kan een ander idee hebben van wat het betekent. Omdat relaties tussen entiteiten meer op een web dan op een boom lijken, kunnen zelfs degenen die het met het web eens zijn, een andere weergave van de boom kiezen. Dit zijn mijn (vaak herhaalde) algemene opmerkingen over de gevaren van hiërarchische classificatie als algemene oplossing.

Wanneer u een onderwerpnaam in een URI gebruikt, verplicht u zich feitelijk tot een bepaalde classificatie. Misschien geeft u in de toekomst de voorkeur aan een andere optie. De URI is dan vatbaar voor schending.

De reden voor het gebruik van een onderwerpgebied als onderdeel van een URI is dat de verantwoordelijkheid voor subsecties van de URI-ruimte meestal wordt gedelegeerd, en dan heb je de naam nodig van de organisatie-instantie (afdeling, groep of wat dan ook) die verantwoordelijk is voor die subruimte. Dit is een URI die aan een organisatiestructuur is gekoppeld. Het is meestal alleen veilig als de verdere (linker) URI wordt beschermd door een datum: 1998/pics kan voor uw server betekenen "wat we in 1998 bedoelden met foto's" in plaats van "wat we in 1998 deden met wat we nu foto's noemen."

Vergeet de domeinnaam niet

Houd er rekening mee dat dit niet alleen geldt voor het pad in de URI, maar ook voor de servernaam. Als je aparte servers hebt voor verschillende dingen, onthoud dan dat deze verdeling onmogelijk te veranderen zal zijn zonder heel veel links te vernietigen. Enkele klassieke "kijk naar de software die we vandaag de dag gebruiken"-fouten zijn domeinnamen "cgi.pathfinder.com", "secure", "lists.w3.org". Ze zijn ontworpen om het serverbeheer eenvoudiger te maken. Ongeacht of een domein een divisie binnen uw bedrijf, een documentstatus, een toegangsniveau of een beveiligingsniveau vertegenwoordigt, wees zeer voorzichtig voordat u meer dan één domeinnaam voor meerdere documenttypen gebruikt. Houd er rekening mee dat u meerdere webservers binnen één zichtbare webserver kunt verbergen met behulp van omleiding en proxying.

Oh, en denk ook aan je domeinnaam. U wilt niet dat er naar soap.com wordt verwezen nadat u van productlijn bent veranderd en bent gestopt met het maken van zeep (sorry voor degene die op dit moment eigenaar is van soap.com).

Conclusie

Het bewaren van een URI voor 2, 20, 200 of zelfs 2000 jaar is uiteraard niet zo eenvoudig als het lijkt. Overal op internet nemen webmasters echter beslissingen die het zichzelf in de toekomst erg moeilijk maken om deze taak uit te voeren. Vaak komt dit doordat ze tools gebruiken die tot taak hebben om alleen op dat moment de beste site te presenteren - en niemand heeft ingeschat wat er met de links zal gebeuren als alles verandert. Het punt hier is echter dat er heel veel dingen kunnen veranderen, en dat uw URI's hetzelfde kunnen en moeten blijven. Dit is alleen mogelijk als je nadenkt over hoe je ze maakt.

Zie Well.:

De tirade van Jakob Nielsen over hetzelfde onderwerp

supplementen

Bestandsextensies verwijderen...

...van een URI in de huidige bestandsgebaseerde webserver?

Als u bijvoorbeeld Apache gebruikt, kunt u dit configureren om over inhoud te onderhandelen. Sla de bestandsextensie (bijvoorbeeld .png) op in een bestand (bijvoorbeeld mijnhond.png), maar u kunt zonder deze link naar een webbron verwijzen. Apache controleert vervolgens de map op alle bestanden met die naam en eventuele extensie, en kan de beste uit de set kiezen (bijvoorbeeld GIF en PNG). En het is niet nodig om verschillende soorten bestanden in verschillende mappen te plaatsen; het matchen van inhoud zal zelfs niet werken als u dat doet.

Stel uw server in om over inhoud te onderhandelen
Koppel altijd naar URI's zonder extensie

Koppelingen met extensies werken nog steeds, maar voorkomen dat uw server het beste formaat kiest dat momenteel en in de toekomst beschikbaar is.

(In werkelijkheid, mydog, mydog.png и mydog.gif — geldige webbronnen, mydog is een universele inhoudsbron, en mydog.png и mydog.gif — bronnen van een specifiek inhoudstype).

Als u uw eigen webserver schrijft, is het natuurlijk een goed idee om een database te gebruiken om persistente identifiers aan hun huidige vorm te binden, maar pas op voor onbeperkte databasegroei.

Het bord van schaamte - Verhaal 1: Kanaal 7

In 1999 heb ik schoolsluitingen als gevolg van sneeuw op pagina bijgehouden http://www.whdh.com/stormforce/closings.shtml. Wacht niet tot de informatie onderaan het tv-scherm verschijnt! Ik heb er vanaf mijn startpagina naar gelinkt. De eerste grote sneeuwstorm van 2000 arriveert en ik controleer de pagina. Daar staat geschreven:,

- Vanaf.
Er is momenteel niets gesloten. Gelieve terug te keren in geval van weerswaarschuwingen.

Het kan niet zo'n sterke storm zijn. Grappig dat de datum ontbreekt. Maar als u naar de hoofdpagina van de site gaat, ziet u 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 gewijzigd, maar hoefden ze de URI niet te wijzigen.

Board of Shame - Verhaal 2: Microsoft Netmeeting

Met de groeiende afhankelijkheid van internet ontstond het slimme idee om links naar de website van de fabrikant in applicaties te kunnen insluiten. Dit is veel gebruikt en misbruikt, maar je kunt de URL niet wijzigen. Onlangs probeerde ik een link van de Microsoft Netmeeting 2/something-client in het menu Help/Microsoft on the Web/Gratis dingen en kreeg een 404-fout - er werd geen antwoord van de server gevonden. Misschien is het al opgelost...

Historische noot: Aan het einde van de 20e eeuw, toen dit werd geschreven, was 'cool' een bijnaam die vooral onder jonge mensen werd gewaardeerd, en die modieusheid, kwaliteit of gepastheid aanduidde. In haast werd het URI-pad vaak gekozen vanwege 'coolheid' in plaats van bruikbaarheid of duurzaamheid. Dit bericht is een poging om de energie achter de zoektocht naar cool te richten.

Bron: www.habr.com

Coole URI's veranderen niet