Autor — sir Tim Berners-Lee, vynálezce URI, URL, HTTP, HTML a World Wide Webu, současný ředitel W3C. Článek byl napsán v roce 1998.

Jaký URI lze považovat za "cool"?
Takový, který se nemění.
Jak se URI mění?
URI se nemění: mění je lidé.

Teoreticky nemají lidé žádný důvod měnit URI (nebo přestat podporovat dokumenty), ale v praxi jich jsou miliony.

Teoreticky, nominální vlastník doménového prostoru skutečně vlastní doménový prostor a tím pádem všechny URI v něm. Kromě platební neschopnosti, nic nebrání vlastníkovi domény udržet si toto jméno. A teoreticky, prostor URI pod vaší doménou je plně pod vaší kontrolou, takže si ho můžete udělat tak stabilním, jak potřebujete. V zásadě je jediným skutečným důvodem, proč dokument zmizí z internetu, to, že společnost, které náleželo doménové jméno, přestala existovat nebo si už nemůže dovolit provozovat server. Proč je tedy v tomto světě tolik nefunkčních odkazů? Částečně to je prostě nedostatek předvídavosti. Tady je několik důvodů, které můžete slyšet:

Jednoduše jsme reorganizovali web, abychom ho zlepšili.

Opravdu si myslíte, že staré URI už nemohou fungovat? Pokud ano, vybrali jste je velmi špatně. Zvažte, zda si je můžete udržet i po další redesignu.

Máme tolik materiálu, že nemůžeme sledovat, co zastaralo, co je důvěrné a co je stále aktuální, a proto jsme si mysleli, že je lepší to všechno prostě vypnout.

Mohu vám jen vyjádřit soustrast. W3C si prošla obdobím, kdy jsme museli důkladně procházet archivní materiály z hlediska důvěrnosti, než jsme je zpřístupnili veřejnosti. Řešení by mělo být promyšlené předem — ujistěte se, že u každého dokumentu zaznamenáte přijatelný okruh čtenářů, datum vytvoření a, ideálně, dobu platnosti. Uchovejte si tato metadata.

No, zjistili jsme, že je třeba přesunout soubory…

To je jedno z nejúbožejších odůvodnění. Mnozí nevědí, že webové servery umožňují spravovat vztah mezi URI objektu a jeho skutečným umístěním v souborovém systému. Představte si prostor URI jako abstraktní prostor, dokonale organizovaný. Poté proveďte zobrazení na jakoukoli realitu, kterou skutečně používáte pro její realizaci. A pak to oznamte webovému serveru. Dokonce můžete napsat část svého serveru, abyste to udělali správně.

John již tuto částku nepodporuje, teď to dělá Jane.

Bylo jméno Johna v URI? Ne, jen byl soubor v jeho adresáři? No jasně.

Dříve jsme pro to používali CGI skript, nyní používáme binární program.

Existuje šílená myšlenka, že stránky vytvořené skripty by měly být umístěny v oblasti "cgibin" nebo "cgi". To odhaluje mechanismus, jak spouštíte svůj webový server. Změníte mechanismus (i když zachováte obsah) a hop — všechny vaše URI se změní.

Vezměme si například Národní vědeckou nadaci (NSF):

Online dokumenty NSF

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

První stránka pro zahájení prohlížení dokumentů jasně nezůstane stejná za několik let. cgi-bin, oldbrowse a pl — to všechno poskytuje částice informací o tom, jak-to-děláme-teď. Pokud však používáte stránku k vyhledávání dokumentu, dostáváte jako první také špatný výsledek:

Zpráva pracovní skupiny pro kryptoanalýzu a teorii kódování

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

pro indexovou stránku dokumentu, i když samotný html dokument vypadá mnohem lépe:

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

Zde nadpis pubs/1998 poskytne jakémukoli budoucímu archivačnímu servisu dobrý klíč k pochopení toho, co funguje v rámci starého systému klasifikace dokumentů z roku 1998. I když v roce 2098 mohou čísla dokumentů vypadat jinak, mohu si představit, že toto URI bude stále platné, a nijak neohrozí NSF nebo jakoukoli jinou organizaci, která bude podporovat archiv.

Nemyslel jsem, že adresy URL by měly být trvalé — byly přece URN.

To je pravděpodobně jeden z nejhorších vedlejších efektů diskuse o URN. Někteří si myslí, že kvůli výzkumům o trvalejším prostoru názvů se mohou nedbale stavět k visícím odkazům, protože «URN to všechno vyřeší». Pokud jste jedním z těchto lidí, nechte se zklamat.

Většina schémat URN, která jsem viděl, vypadá jako identifikátor autority, za kterým následuje buď datum a řetězec, který si vyberete, nebo jen řetězec, který si vyberete. Je to velmi podobné HTTP URI. Jinými slovy, pokud si myslíte, že vaše organizace bude schopna vytvářet dlouhodobé URN, dokažte to nyní tím, že je použijete pro své HTTP URI. V samotném HTTP neexistuje nic, co by váš URI činilo nestabilním. Pouze vaše organizace. Vytvořte databázi, která mapuje URN dokumentu na aktuální název souboru, a nechte webový server použít ji k faktickému vytažení souborů.

Pokud jste se dostali až sem, a pokud nemáte čas, peníze a kontakty na vývoj nějakého softwaru, můžete uvést následující omluvu:

Chtěli jsme, ale prostě nemáme potřebné nástroje.

Tímto se dá soucítit. Naprosto souhlasím. Co potřebujete udělat, je donutit webový server, aby okamžitě zpracoval trvalé URI a vrátil soubor, ať už je nyní kdekoli ve vaší aktuální bláznivé souborové struktuře. Chcete uchovávat všechna URI v souboru jako ověření a neustále udržovat databázi v aktuálnosti. Chcete uchovat vztahy mezi různými verzemi a překlady stejného dokumentu a také uchovat nezávislý záznam kontrolního součtu, abyste zajistili ochranu před poškozením souboru náhodnou chybou. A webové servery prostě nefungují s těmito funkcemi hned od začátku. Když chcete vytvořit nový dokument, váš editor vás žádá, abyste zadali URI.

Potřebujete možnost měnit vlastnictví, přístup k dokumentu, úroveň zabezpečení archivační úrovně a další v prostoru URI bez změny URI.

Všechno je příliš špatné. Ale situaci napravíme. V W3C používáme funkčnost Jigedit (server Jigsaw pro editaci), který sleduje verze, a experimentujeme se skripty na vytváření dokumentů. Pokud vyvíjíte nástroje, servery a klienty, věnujte pozornost tomuto problému!

Tato omluva se vztahuje i na mnohé stránky W3C, včetně této: takže dělejte to, co říkám, a ne to, co dělám.

Proč by mě to mělo zajímat?

Když změníte URI na svém serveru, nikdy nemůžete s jistotou říct, kdo bude mít odkazy na staré URI. Může to být odkazy z běžných webových stránek. Záložky na vaši stránku. URI mohlo být napsáno na okrajích dopisu příteli.

Když někdo klikne na odkaz a ten nefunguje, obvykle ztrácí důvěru k majiteli serveru. Je také zklamaný – jak emocionálně, tak reálně z neschopnosti dosáhnout svého cíle.

Mnoho lidí neustále si stěžuje na nefunkční odkazy, a doufám, že škoda je jasná. Doufám, že také je jasné reputační poškození správci serveru, kde dokument zmizel.

Co tedy mám dělat? Návrh URI

Je povinností webmastra navrhnout URI, která budou použitelná za 2 roky, za 20 let, za 200 let. K tomu je potřeba promyšlenost, organizovanost a cílevědomost.

URI se mění, pokud se změní nějaké informace. Je velmi důležité, jak je navrhujete. (Co, návrh URI? Mám navrhovat URI? Ano, měli byste o tom přemýšlet). Návrh v podstatě znamená nepřidávat žádné informace do URI.

Datum vytvoření dokumentu – datum vydání URI – je něco, co se nikdy nezmění. Je to velmi užitečné pro oddělení požadavků, které používají nový systém, od těch, které používají starý systém. Je dobré začít URI tímto datem. Pokud je na dokumentu uvedeno nějaké datum, i když dokument bude aktuální i v budoucnu, je to dobrý začátek.

Jedinou výjimkou je stránka, která je záměrně „poslední“ verzí, například pro celou organizaci nebo její velkou část.

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

Tohle je poslední sloupek Money Daily v časopise Money. Hlavním důvodem, proč v tomto URI není potřeba datum, je, že neexistují žádné důvody k uchování URI, které přežije časopis. Koncept Money Daily zmizí, jakmile časopis zanikne. Pokud chcete odkazovat na obsah, měli byste na něj odkazovat zvlášť v archivech:

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

(Vypadá to dobře. Předpokládá, že "money" bude mít po celou dobu existence pathfinder.com stejný význam. Existuje zde duplicita "98" a nepotřebné ".html", ale jinak vypadá jako silné URI.

Co nechat stranou

Všechno! Kromě data vytvoření, vkládat jakékoli informace do URI si nepřímo říkáte o problémy.

Jméno autora. Autorship can change with the release of new versions. People leave organizations and pass things on to others.
Předmět. It's very complex. It always looks good at first, but it changes surprisingly quickly. I'll elaborate on this below.
Stav. Categories like 'old', 'draft', and so on, not to mention 'latest' and 'cool', appear in all file systems. Documents change status — otherwise, there would be no point in creating drafts. The latest version of a document needs a constant identifier, regardless of its status. Keep the status out of the name.
Přístup. At W3C, we divided the site into sections for staff, members, and the public. It sounds good, but of course documents start as team ideas from staff, are discussed with members, and then become public. It's really unfortunate if every time a document is opened for wider discussion, all the old links to it break! Now we move to simple date code.
Přípona souboru. A very common phenomenon. "cgi", even ".html" will change in the future. Perhaps in 20 years you won't be using HTML for that page, but today's links to it must still work. Canonical links on the W3C site do not use extensions (jak to udělat).
Programové mechanismy. In the URI, look for "cgi", "exec", and other terms that scream 'look at what software we are using'. Does anyone want to dedicate their life to Perl CGI scripts? No? Then remove the .pl extension. Read the server guide on how to do this.
Jméno disku. No tak! Ale já to viděl.

So the best example from our site is simply

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

… the report of the W3C chair meeting.

Témata a klasifikace podle témat

O této hrozbě vám podrobněji povím, protože to je jedna z těch věcí, kterým se nejhůře vyhýbá. Obvykle se témata dostávají do URI, když klasifikujete své dokumenty podle vykonávané práce. Ale toto rozdělení se časem změní. Názvy oblastí se změní. Ve W3C jsme chtěli změnit MarkUP na Markup a poté na HTML, aby to odráželo aktuální obsah sekce. Navíc, často je zde plochý prostor názvů. Za 100 let si jste jisti, že nebudete chtít nic znovu použít? Už během našeho krátkého života jsme chtěli znovu použít „Historii“ a „Stylové tabulky“, například.

To je lákavý způsob organizace webové stránky — a skutečně lákavý způsob organizace čehokoliv, včetně celé Sítě. Je to skvělé střednědobé řešení, ale má vážné nedostatky z dlouhodobého hlediska.

Částečně důvody spočívají v filozofii smyslu. Každý termín v jazyce je potenciálním objektem klasifikace a každý člověk si může mít různé představy o tom, co to znamená. Protože vztahy mezi subjekty spíše připomínají pavučinu než strom, i ti, kdo souhlasí s pavučinou, si mohou vybrat jiné znázornění stromu. Toto jsou mé (často opakované) obecné poznámky o nebezpečích hierarchické klasifikace jako obecného řešení.

Ve skutečnosti, když použijete jméno téma v URI, zavazujete se k určité klasifikaci. Možná v budoucnu budete preferovat jinou variantu. Tehdy bude URI vystaveno porušení.

Důvod použití tematické oblasti jako části URI spočívá v tom, že odpovědnost za podsekce prostoru URI je obvykle delegována, a pak potřebujete jméno organizačního orgánu — oddělení, skupiny nebo něco jiného, co nese odpovědnost za toto podsíť. Tato vazba URI na organizační strukturu je obvykle bezpečná pouze tehdy, když je dále (nalevo) URI chráněno datem: 1998/pics může pro váš server znamenat „to, co jsme měli na mysli v roce 1998 pod pics“, a ne „to, co jsme v roce 1998 udělali s tím, co nyní nazýváme pics.“

Nezapomeňte na doménové jméno

Pamatujte, že to platí nejen pro cestu v URI, ale i pro název serveru. Pokud máte oddělené servery pro různé účely, nezapomeňte, že toto rozdělení nebude možné změnit, aniž byste zničili mnoho a mnoho odkazů. Některé klasické chyby typu „podívejte se, jaký software dnes používáme“ – doménová jména "cgi.pathfinder.com", "secure", "lists.w3.org". Byla vytvořena za účelem usnadnění správy serverů. Ať už doména představuje jakékoli oddělení ve vaší společnosti, status dokumentu, úroveň přístupu nebo bezpečnosti, buďte velmi, velmi opatrní, než začnete používat více než jedno doménové jméno pro více typů dokumentů. Pamatujte, že mnoho webových serverů můžete skrýt za jedním viditelným webovým serverem pomocí přesměrování a proxy serveru.

Ano, a také přemýšlejte o svém doménovém jménu. Nechcete přece, aby vás odkazovali jako na soap.com poté, co změníte produktovou řadu a přestanete vyrábět mýdlo (omlouvám se tomu, kdo momentálně vlastní soap.com).

Závěr

Udržet URI po dobu 2, 20, 200 nebo dokonce 2000 let, očividně není tak snadné, jak se zdá. Nicméně na celém internetu webmasteři činí rozhodnutí, která si skutečně ztěžují tento úkol v budoucnu. Často se to děje proto, že používají nástroje, jejichž úkolem je představit nejlepší web pouze v daném okamžiku – a nikdo si neuvědomil, co se stane s odkazy, když se všechno změní. Podstatou však je, že se může a musí toho hodně, opravdu hodně, změnit, a vaše URI mohou a měly by zůstat stejné. To je možné pouze tehdy, když přemýšlíte o tom, jak je vytváříte.

Viz také:

Tirád Jakoba Nielsena na stejné téma

Doplňky

Jak odstranit přípony souborů...

…z URI v aktuálním webovém serveru na základě souborů?

Pokud používáte například Apache, můžete ho nakonfigurovat tak, aby souhlasil s obsahem. Uchováváte příponu souboru (například .png) v souboru (například, mydog.png), ale na webový zdroj se lze odkazovat i bez něj. Apache následně prozkoumá adresář, aby našel všechny soubory s tímto názvem a libovolnou příponou, a může vybrat ten nejlepší z dostupného souborového typu (například GIF a PNG). A není nutné umisťovat různé typy souborů do různých adresářů, ve skutečnosti bude shoda obsahu fungovat pouze v případě, že to neuděláte.

Nastavte svůj server na shodu obsahu
Vždy odkazujte na URI bez přípony

Odkazy s příponami stále fungují, ale neumožní vašemu serveru vybrat nejlepší dostupný a budoucí formát.

(Ve skutečnosti, mojepes, mydog.png a mydog.gif — platné webové zdroje, mojepes — je to zdroj univerzálního typu obsahu, a mydog.png a mydog.gif — zdroje konkrétního typu obsahu).

Samozřejmě, pokud píšete vlastní webový server, bylo by dobré použít databázi pro asociaci trvalých identifikátorů s jejich aktuální formou, přičemž si dejte pozor na neomezený růst databáze.

Ostuda — Příběh 1: Channel 7

Během roku 1999 jsem sledoval uzavření škol kvůli sněhu na stránce http://www.whdh.com/stormforce/closings.shtml. Nebylo by dobré čekat, až se informace objeví na spodní části televizní obrazovky! Vložil jsem na ni odkaz ze své domovské stránky. Přišel první velký sněhový vítr roku 2000 a kontroloval jsem stránku. Bylo tam napsáno:,

— K datu.
V tuto chvíli není nic uzavřeno. Prosím, vraťte se v případě výstrah před počasím.

Nemůže být, že by tak silná bouře. Je legrační, že datum chybí. Ale pokud přejdete na domovskou stránku webu, bude tam velké tlačítko „Uznávané školy“, které vede na stránku http://www.whdh.com/stormforce/ s dlouhým seznamem uzavřených škol.

Možná změnili systém pro získání seznamu — ale URI měnit nemuseli.

Ostuda — Příběh 2: Microsoft Netmeeting

Se stále rostoucí závislostí na internetu přišla chytrá myšlenka, aby se do aplikací vkládaly odkazy na web výrobce. To bylo často používáno a silně zneužíváno, ale — URL nelze měnit. Doslova před pár dny jsem zkoušel odkaz z klienta Microsoft Netmeeting 2/something v menu Nápověda/Microsoft na webu/Zdarma a dostal jsem chybu 404 — odpověď serveru nenalezena. Možná to už opravili…

Historická poznámka: na konci 20. století, kdy byl tento text napsán, bylo slovo „cool“ výrazem schválení, zejména mezi mladými lidmi, naznačujícím módnost, kvalitu nebo vhodnost. Při rychlém výběru cesty URI se často volila „cool“ alternativa, nikoli s ohledem na užitečnost nebo trvanlivost. Tato poznámka se snaží přesměrovat energii, která stojí za hledáním coolness.

Zdroj: habr.com