Autorem je Sir Tim Berners-Lee, vynálezce URI, URL, HTTP, HTML a World Wide Webu a současný šéf W3C. Tento článek byl napsán v roce 1998.

Který URI je považován za „cool“?
Takový, který se nemění.
Jak se mění URI?
URI se nemění: mění je lidé.

Teoreticky neexistuje důvod, aby lidé měnili URI (nebo přestali podporovat dokumenty), ale v praxi jich jsou miliony.

Teoreticky nominální vlastník doménového jmenného prostoru ve skutečnosti vlastní tento doménový jmenný prostor a tedy i všechny URI v něm. Kromě insolvence nic nebrání vlastníkovi doménového jména v jeho ponechání. A teoreticky je prostor URI pod vaším doménovým jménem plně pod vaší kontrolou, takže si ho můžete dle libosti stabilizovat. Prakticky jediným platným důvodem, proč dokument zmizí z internetu, je to, že společnost, která doménové jméno vlastnila, zkrachovala nebo si již nemůže dovolit udržovat svůj server. Proč tedy chybí tolik odkazů? Částečně je to prostě nedostatek předvídavosti. Zde je několik důvodů, které můžete slyšet:

Prostě jsme web zreorganizovali, aby byl lepší.

Opravdu si myslíte, že staré URI už nebudou fungovat? Pokud ano, udělali jste velmi špatnou volbu. Zvažte ponechání nových i po příštím redesignu.

Máme tolik materiálu, že si nedokážeme udržet přehled o tom, co je zastaralé, co je citlivé a co je stále relevantní, takže jsme si mysleli, že by bylo lepší to všechno prostě vypnout.

Mohu jen soucítit. W3C prošla obdobím, kdy jsme museli pečlivě prověřovat důvěrnost archivovaných materiálů, než jsme je zveřejnili. Rozhodnutí by mělo být předem promyšlené – ujistěte se, že u každého dokumentu zaznamenáte přijatelnou cílovou skupinu, datum vytvoření a ideálně i datum platnosti. Uchovejte tato metadata.

No, zjistili jsme, že potřebujeme přesunout soubory…

Tohle je jedna z nejpatetičtějších výmluv. Mnoho lidí si neuvědomuje, ž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í, dokonale organizovaný prostor. Pak ho namapujte na jakoukoli realitu, kterou skutečně použijete k jeho implementaci. Pak o tom webovému serveru řekněte. Můžete si dokonce napsat vlastní část pro server, abyste to udělali správně.

Jan už tento soubor nespravuje, teď ano Jana.

Bylo v URI Johnovo jméno? Ne, soubor byl jen v jeho adresáři? Dobře, už chápu.

Dříve jsme k tomu používali CGI skript, ale teď používáme binární program.

Existuje šílená představa, že stránky generované skripty musí být umístěny v doméně „cgibin“ nebo „cgi“. To odhaluje mechanismus, jakým provozujete webový server. Změňte mechanismus (i při zachování obsahu) a jejda – všechny vaše URI se změní.

Vezměte 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ů se za pár let zjevně nezmění. cgi-bin, oldbrowse и pl — to vše poskytuje kousky informací o tom, jak to teď děláme. Pokud stránku použijete k vyhledávání dokumentu, dostanete nejprve stejně špatný výsledek:

Zpráva pracovní skupiny pro kryptologii a teorii kódování

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

pro indexovou stránku dokumentu, ačkoli samotný HTML dokument vypadá mnohem lépe:

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

Záhlaví pubs/1998 zde poskytne jakékoli budoucí archivní službě dobrou indicii, že platí staré schéma klasifikace dokumentů z roku 1998. I když čísla dokumentů mohou v roce 2098 vypadat jinak, dovedu si představit, že toto URI bude stále platné a nebude bránit NSF ani žádné jiné organizaci, která archiv spravuje.

Nemyslel jsem si, že URL adresy musí být trvalé – existovaly URN.

To je pravděpodobně jeden z nejhorších vedlejších účinků debaty o URN. Někteří lidé si myslí, že výzkum perzistentnějších jmenných prostorů jim umožňuje být laxní k visícím odkazům, protože „URN to všechno vyřeší“. Pokud patříte k těmto lidem, dovolte mi, abych vás zklamal.

Většina schémat URN, která jsem viděl, vypadá jako identifikátor autority následovaný buď datem a řetězcem dle vašeho výběru, nebo jen řetězcem dle vašeho výběru. To je 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í jejich použitím pro vaše HTTP URI. V samotném HTTP není nic, co by způsobovalo nestabilitu vašeho URI. Pouze vaše organizace. Vytvořte databázi, která mapuje URN dokumentu na aktuální název souboru, a nechte webový server, aby ji použil k načtení souborů.

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

Chtěli jsme, ale prostě nemáme správné nástroje.

S tím teď můžu soucítit. Naprosto souhlasím. Co musíte udělat, je donutit webový server, aby okamžitě zpracoval perzistentní URI a vrátil soubor, ať je aktuálně uložen kdekoli ve vašem aktuálním, šíleném souborovém systému. Chcete ukládat všechny URI do souboru jako kontrolu a neustále udržovat databázi aktuální. Chcete zachovat vztahy mezi různými verzemi a překlady stejného dokumentu a také udržovat nezávislý záznam kontrolního součtu, abyste chránili před poškozením souboru v důsledku náhodné chyby. A webové servery tyto funkce jednoduše nemají ihned po instalaci. Když chcete vytvořit nový dokument, váš editor vás požádá o zadání URI.

Potřebujete mít možnost změnit vlastnictví, přístup k dokumentům, zabezpečení na úrovni archivu atd. v prostoru URI bez změny URI.

Je to škoda. Ale opravíme to. Ve W3C používáme Jigedit (server Jigsaw pro úpravy) ke sledování verzí a experimentujeme se skripty pro generování dokumentů. Pokud vyvíjíte nástroje, servery a klienty, věnujte prosím tomuto problému pozornost!

Toto zdůvodnění platí i pro mnoho stránek W3C, včetně této: takže dělejte, co říkám, ne to, co dělám já.

Proč by mi to mělo vadit?

Když změníte URI na svém serveru, nikdy si nemůžete být zcela jisti, kdo bude odkazovat na staré URI. Mohou to být odkazy z běžných webových stránek, záložky na vaši stránku nebo URI mohlo být načmárané na okraji dopisu příteli.

Když někdo klikne na odkaz a ten je nefunkční, obvykle ztratí důvěru ve vlastníka serveru. Je také zklamán – emocionálně i fyzicky – z toho, že nedosáhl svého cíle.

Mnoho lidí si neustále stěžuje na nefunkční odkazy a doufám, že škoda je zřejmá. Doufám, že je zřejmá i škoda na pověsti správce serveru, kde dokument zmizel.

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

Je odpovědností webmastera přidělit URI, které budou použitelné za dva roky, 20 let nebo 200 let. To vyžaduje přemýšlení, organizaci a odhodlání.

URI se mění, když se změní jakákoli informace v nich. Způsob, jakým je navrhujete, je klíčový. (Cože, design URI? Musím navrhovat URI? Ano, o tom byste měli přemýšlet.) Design v podstatě znamená vynechat jakékoli informace z URI.

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

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

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

Toto je poslední sloupek časopisu Money Daily. Hlavním důvodem, proč tento URI nepotřebuje datum, je to, že neexistuje důvod udržovat URI, které by přežilo časopis. Koncept Money Daily zmizí, když zanikne Money. Pokud chcete odkazovat na obsah, měli byste na něj odkazovat samostatně v archivu:

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

(Vypadá to dobře. Předpokládá se, že „peníze“ bude znamenat totéž po celou dobu existence pathfinder.com. Je tam duplicitní „98“ a zbytečný „.html“, ale jinak to vypadá jako silný URI.)

Co nechat stranou

To je vše! Kromě data vytvoření si vkládání jakýchkoli informací do URI tak či onak koleduje o potíže.

Jméno autoraAutorství se může měnit s objevením nových verzí. Lidé opouštějí organizace a předávají věci ostatním.
PředmětJe to velmi těžké. Zpočátku to vždycky vypadá dobře, ale překvapivě rychle se to změní. O tom budu podrobněji mluvit níže.
PostaveníAdresáře jako „starý“, „koncept“ atd., nemluvě o „nejnovějším“ a „skvělé“, se vyskytují ve všech souborových systémech. Dokumenty mění stav – jinak by nemělo smysl vytvářet koncepty. Nejnovější verze dokumentu vyžaduje trvalý identifikátor bez ohledu na jeho stav. Stav uchovávejte odděleně od názvu.
PřístupVe W3C jsme rozdělili web do sekcí pro zaměstnance, členy a veřejnost. To zní dobře, ale dokumenty samozřejmě začínají jako týmové nápady od zaměstnanců, jsou diskutovány s členy a poté se stanou veřejně dostupnými. Byla by opravdu škoda, kdyby pokaždé, když je dokument otevřen k širší diskusi, všechny staré odkazy na něj přestaly fungovat! Nyní přecházíme na jednoduchý datový kód.
Přípona souboruToto se stává velmi běžně. „cgi“, dokonce i „.html“, se v budoucnu změní. Možná za 20 let pro tuto stránku nebudete používat HTML, ale odkazy na ni by dnes měly stále fungovat. Kanonické odkazy na webu W3C nepoužívají příponu ().jak se to dělá).
Softwarové mechanismyHledejte v URI výrazy „cgi“, „exec“ a další výrazy, které křičí „podívejte se na software, který používáme“. Chce někdo zasvětit celý svůj život Perlovým CGI skriptům? Ne? Pak odstraňte příponu .pl. Přečtěte si pokyny v manuálu k serveru.
Název disku. No tak! Ale už jsem takové věci viděl.

Takže nejlepším příkladem z našich stránek je právě

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

…zpráva o zápisu ze schůze předsedů W3C.

Témata a klasifikace podle témat

O tomto nebezpečí se budu podrobněji zabývat, protože je to jedna z nejtěžších věcí, kterým se lze vyhnout. Témata jsou obvykle zahrnuta v URI, když kategorizujete dokumenty podle jejich práce. Toto rozdělení se však bude časem měnit. Názvy oblastí se budou měnit. Ve W3C jsme chtěli změnit MarkUP na Markup a poté na HTML, aby odrážel skutečný obsah sekce. Také často existuje plochý jmenný prostor. Jste si jisti, že za 100 let nebudete chtít nic znovu použít? Za naši krátkou dobu jsme už chtěli znovu použít například „Historii“ a „Stylové listy“.

Je to lákavý způsob, jak uspořádat webové stránky – a skutečně lákavý způsob, jak uspořádat cokoli, včetně celého webu. Je to skvělé střednědobé řešení, ale z dlouhodobého hlediska má vážné nevýhody.

Část důvodu spočívá ve filozofii významu. Každý termín v jazyce je potenciálním objektem shlukování a každý člověk může mít jinou představu o tom, co znamená. Vzhledem k tomu, že vztahy mezi entitami se spíše podobají pavučině než stromu, i ti, kteří pavučinu akceptují, si mohou zvolit jinou reprezentaci stromu. Toto jsou moje (často opakovaná) obecná pozorování o nebezpečích hierarchické klasifikace jako obecného řešení.

V podstatě, když v URI použijete název tématu, zavazujete se k určité klasifikaci. V budoucnu můžete zvolit jinou možnost a URI bude zranitelné vůči poškození.

Důvodem pro použití předmětové oblasti jako součásti URI je to, že odpovědnost za podsekce prostoru URI je obvykle delegována, a poté potřebujete název organizační jednotky – divize, skupiny nebo čehokoli jiného – která je za tento podprostor zodpovědná. Tím se URI ukotví v organizační struktuře. Obvykle je to bezpečné pouze tehdy, když je URI dále vlevo, chráněné datem: 1998/pics může pro váš server znamenat „to, co jsme v roce 1998 mysleli pod pojmem pics“, nikoli „co jsme v roce 1998 udělali s tím, čemu dnes říkáme pics“.

Nezapomeňte na název domény

Nezapomeňte, že se to týká nejen cesty v URI, ale také názvu serveru. Pokud máte oddělené servery pro různé účely, nezapomeňte, že toto oddělení nebude možné změnit bez přerušení mnoha odkazů. Mezi klasické chyby typu „podívejte se na software, který dnes používáme“ patří názvy domén jako „cgi.pathfinder.com“, „secure“ a „lists.w3.org“. Tyto názvy jsou navrženy tak, aby usnadnily správu serveru. Bez ohledu na to, zda doména představuje oddělení ve vaší společnosti, stav dokumentu, úroveň přístupu nebo úroveň zabezpečení, buďte velmi opatrní, než použijete více než jeden název domény pro více typů dokumentů. Nezapomeňte, že můžete skrýt více webových serverů v rámci jednoho viditelného webového serveru pomocí přesměrování a proxyingu.

A zamyslete se nad svým doménovým jménem. Nechcete být po změně produktové řady a ukončení výroby mýdla odkazováni jako soap.com (omlouvám se tomu, kdo v současnosti vlastní soap.com).

Závěr

Udržování URI po dobu 2, 20, 200 nebo dokonce 2 000 let zjevně není tak snadné, jak se zdá. Přesto na internetu správci webů dělají rozhodnutí, která jim tento úkol v budoucnu skutečně ztěžují. Často je to proto, že používají nástroje určené k prezentaci co nejlepšího webu pouze v daném okamžiku – bez ohledu na to, co se stane s odkazy, až se věci změní. Jde však o to, že se může změnit mnoho, mnoho věcí a vaše URI mohou a měly by zůstat stejné. To je možné pouze tehdy, pokud si pečlivě promyslíte, jak je vytváříte.

Viz také:

Tiráda Jakoba Nielsena na stejné téma

Přírůstky

Jak odstranit přípony souborů…

...z URI v aktuálním webovém serveru založeném na souborech?

Pokud například používáte Apache, můžete jej nakonfigurovat tak, aby vyjednával obsah. Příponu souboru (např. .png) uložíte do souboru (např. můjpes.png), ale můžete odkazovat na webový zdroj i bez něj. Apache pak zkontroluje adresář, zda neobsahuje všechny soubory s daným názvem a libovolnou příponou, a z dané sady může vybrat ten nejlepší (například GIF a PNG). A není třeba umisťovat různé typy souborů do různých adresářů; ve skutečnosti nebude vyjednávání obsahu fungovat, pokud to uděláte.

Konfigurace serveru pro vyjednávání obsahu
Vždy odkazujte na URI bez přípon.

Odkazy s příponami budou stále fungovat, ale zabrání vašemu serveru ve výběru nejlepšího formátu ze aktuálně i budoucích dostupných formátů.

(Ve skutečnosti, mydog, mydog.png и mydog.gif - platné webové zdroje, mydog — je zdrojem univerzálního typu obsahu a mydog.png и mydog.gif — zdroje specifického typu obsahu).

Samozřejmě, pokud si píšete vlastní webový server, je vhodné použít databázi k mapování perzistentních identifikátorů do jejich aktuální podoby, ale pozor na neomezený růst databáze.

Síň hanby - Příběh 1: Kanál 7

V průběhu roku 1999 jsem na stránce sledoval uzavírání škol kvůli sněhu. http://www.whdh.com/stormforce/closings.shtmlNemohl jsem se dočkat, až se informace objeví ve spodní části televizní obrazovky! Odkazoval jsem na ni ze své domovské stránky. Udeřila první velká sněhová bouře roku 2000 a já se na stránku podíval. Stálo tam:

— K datu.
Momentálně nejsou žádné uzavírky. Pokud budou vydána varování před počasím, vraťte se prosím.

To nemůže být pravda, byla to prostě tak silná bouře. Je vtipné, že tam není datum. Ale když jdete na hlavní stránku webu, je tam velké tlačítko s nápisem „Uzavřené školy“, které vede na stránku. http://www.whdh.com/stormforce/ s dlouhým seznamem zavřených škol.

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

Síň hanby - Příběh 2: Microsoft Netmeeting

S naší rostoucí závislostí na internetu se objevil chytrý nápad: vkládat odkazy na webové stránky výrobce do aplikací. Toto se používá často a velmi zneužívá, ale URL adresu změnit nelze. Zrovna nedávno jsem zkusil odkaz z klienta Microsoft Netmeeting 2 v nabídce 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, byl výraz „cool“ schvalovacím termínem, zejména mezi mladými lidmi, označujícím módnost, kvalitu nebo relevanci. Ve spěchu najít cestu se URI často řídilo spíše „cool“ než užitečností nebo dlouhověkostí. Tato poznámka je pokusem přesměrovat energii stojící za hledáním cool.

Zdroj: www.habr.com