Skvělé URI se nemění

Autor: Sir Tim Berners-Lee, vynálezce URI, URL, HTTP, HTML a World Wide Web a současný šéf W3C. Článek napsaný v roce 1998

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

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

Teoreticky nominální vlastník doménového jmenného prostoru ve skutečnosti vlastní doménový jmenný prostor a tedy všechny URI v něm. Majiteli doménového jména kromě insolvence nic nebrání si jméno ponechat. A teoreticky je prostor URI pod názvem vaší domény zcela pod vaší kontrolou, takže jej můžete vytvořit tak stabilní, jak chcete. V podstatě jediným dobrým důvodem pro to, aby dokument zmizel z internetu, je to, že společnost, která vlastnila název domény, ukončila činnost nebo si již nemůže dovolit udržovat server v chodu. Proč tedy na světě chybí tolik článků? Něco z toho je prostě nedostatek předvídavosti. Zde je několik důvodů, které můžete slyšet:

Právě jsme přeorganizovali web, aby byl lepší.

Opravdu si myslíte, že staré URI už nemohou fungovat? Pokud ano, pak jste je vybrali velmi špatně. Zvažte ponechání nových pro příští redesign.

Máme tolik věcí, že nemůžeme sledovat, co je zastaralé, co je důvěrné a co je stále aktuální, takže jsme si řekli, že bude nejlepší to všechno prostě vypnout.

Mohu jen sympatizovat. W3C prošlo obdobím, kdy jsme před zveřejněním museli pečlivě probírat archivní materiály, aby byly důvěrné. Rozhodnutí by mělo být promyšleno předem – ujistěte se, že u každého dokumentu zaznamenáte přijatelnou čtenost, datum vytvoření a ideálně i datum expirace. Uložte tato metadata.

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

To je jedna z nejpatetičtějších výmluv. Mnoho lidí neví, že webové servery umožňují řídit vztah mezi URI objektu a jeho skutečným umístěním v systému souborů. Představte si prostor URI jako abstraktní prostor, dokonale organizovaný. Pak proveďte mapování k jakékoli realitě, kterou skutečně používáte k jejímu uskutečnění. Pak to nahlaste webovému serveru. Můžete dokonce napsat svůj vlastní fragment serveru, abyste to měli správně.

John již tento soubor neudržuje, Jane nyní ano.

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

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

Existuje bláznivá myšlenka, že stránky vytvořené pomocí skriptů by se měly nacházet v oblasti „cgibin“ nebo „cgi“. To odhaluje mechaniku toho, jak provozujete webový server. Změníte mechanismus (dokonce i při ukládá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, která začne prohlížet dokumenty, zjevně nezůstane za několik let stejná. cgi-bin, oldbrowse и pl - to vše poskytuje informace o tom, jak to nyní děláme. Pokud použijete stránku k hledání dokumentu, první výsledek, který dostanete, je stejně špatný:

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

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

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

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

Zde hlavička pubs/1998 poskytne jakékoli budoucí archivní službě dobré vodítko, že staré schéma klasifikace dokumentů z roku 1998 je účinné. Přestože čísla dokumentů mohou v roce 2098 vypadat jinak, představoval bych si, že toto URI bude stále platné a nebude zasahovat do NSF ani jiné organizace, která by archiv udržovala.

Nemyslel jsem si, že adresy URL musí být trvalé - byly tam URN.

To je pravděpodobně jeden z nejhorších vedlejších účinků debaty o URN. Někteří lidé si myslí, že kvůli výzkumu trvalejšího jmenného prostoru by mohli být lhostejní k zavěšení odkazů, protože „URN to všechno vyřeší“. Pokud jste jedním z těchto lidí, dovolte mi, abych vás zklamal.

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ý vyberete, nebo jen řetězec, který vyberete. To je velmi podobné HTTP URI. Jinými slovy, pokud si myslíte, že vaše organizace bude schopna vytvářet trvalé URN, dokažte to nyní tím, že je použijete pro své HTTP URI. V samotném HTTP není nic, co by způsobilo nestabilitu vašeho URI. Pouze vaše organizace. Vytvořte databázi, která mapuje URN dokumentu k aktuálnímu názvu souboru, a nechte webový server, aby ji použil ke skutečnému načtení souborů.

Pokud jste dosáhli tohoto bodu, pokud nemáte čas, peníze a spojení na vývoj nějakého softwaru, můžete uvést následující omluvu:

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

Ale s tímhle se dá sympatizovat. Naprosto souhlasím. Co musíte udělat, je donutit webový server, aby okamžitě analyzoval trvalé URI a vrátil soubor tam, kde je aktuálně uložen ve vašem aktuálním šíleném systému souborů. Chcete uložit všechny URI do souboru jako kontrolu a udržovat databázi vždy aktuální. Chcete zachovat vztah mezi různými verzemi a překlady stejného dokumentu a také udržovat záznam nezávislého kontrolního součtu, abyste zajistili, že soubor nebude poškozen náhodnou chybou. A webové servery s těmito funkcemi jednoduše nevyjdou z krabice. Když chcete vytvořit nový dokument, váš editor vás požádá o zadání URI.

Musíte 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 všechno moc špatné. Ale situaci napravíme. Ve W3C používáme funkci Jigedit (server pro úpravy Jigsaw), která sleduje verze, a experimentujeme se skripty pro vytváření dokumentů. Pokud vyvíjíte nástroje, servery a klienty, věnujte pozornost tomuto problému!

Tato výmluva platí také pro mnoho stránek W3C, včetně této: dělejte tedy, co říkám, ne jak dělám.

Proč bych se měl starat?

Když změníte URI na vašem serveru, nikdy nemůžete zcela určit, kdo bude mít odkazy na staré URI. Mohou to být odkazy z běžných webových stránek. Přidejte si stránku do záložek. URI mohlo být načmárané na okraji dopisu příteli.

Když někdo následuje odkaz a je nefunkční, obvykle ztratí důvěru v vlastníka serveru. Je také frustrovaný, emocionálně i fyzicky, z toho, že není schopen dosáhnout svého cíle.

Spousta lidí si neustále stěžuje na nefunkční odkazy a já doufám, že škoda je zřejmá. Doufám, že poškození reputace správce serveru, kde dokument zmizel, je také zřejmé.

Tak co bych měl dělat? Návrh URI

Je odpovědností správce webu přidělit URI, které lze použít za 2 roky, za 20 let, za 200 let. To vyžaduje ohleduplnost, organizaci a odhodlání.

URI se změní, pokud se v nich změní nějaké informace. Jak je navrhnete, je velmi důležité. (Co, návrh URI? Musím navrhnout URI? Ano, měli byste o tom přemýšlet). Design v podstatě znamená vynechání jakýchkoli informací v 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í dotazů, které používají nový systém, od těch, které používají starý systém. Toto je dobré místo, kde začít s URI. Pokud je dokument datován, i když bude relevantní 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 nejnovější sloupek Money Daily v časopise Money. Hlavním důvodem, proč v tomto URI není potřeba datum, je to, že není důvod ukládat URI, které přežije protokol. Koncept Money Daily zmizí, když zmizí peníze. Pokud chcete odkazovat na obsah, měli byste na něj odkazovat samostatně v archivech:

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

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

Co nechat stranou

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

  • Jméno autora. Autorství se může změnit, jakmile budou k dispozici nové verze. Lidé opouštějí organizace a předávají věci jiným.
  • Předmět. Je to velmi obtížné. Na první pohled to vždy vypadá dobře, ale překvapivě rychle se mění. Více o tom budu mluvit níže.
  • Postavení. Adresáře jako "starý", "koncept" a tak dále, nemluvě o "nejnovějším" a "cool", se objevují ve všech souborových systémech. Dokumenty mění stav – jinak by nemělo smysl vytvářet koncepty. Nejnovější verze dokumentu potřebuje trvalý identifikátor bez ohledu na jeho stav. Udržujte stav mimo jméno.
  • Přístup. Ve W3C jsme web rozdělili 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 se členy a poté se stávají veřejně známými. Byla by opravdu škoda, kdyby se při každém otevření dokumentu k širší diskusi přerušily všechny staré odkazy na něj! Nyní přejdeme k jednoduchému datovému kódu.
  • Přípona souboru. Velmi častý jev. "cgi", dokonce i ".html" se v budoucnu změní. Možná už za 20 let pro tuto stránku nepoužíváte HTML, ale dnešní odkazy na ni by měly stále fungovat. Kanonické odkazy na webu W3C nepoužívají rozšíření (jak se to dělá).
  • Softwarové mechanismy. V URI hledejte „cgi“, „exec“ a další výrazy, které křičí „podívejte se, jaký software používáme“. Chce někdo strávit celý svůj život psaním Perl CGI skriptů? Ne? Poté odeberte příponu .pl. Přečtěte si manuál k serveru, jak to udělat.
  • Název disku. Pojď! Ale tohle jsem viděl.

Nejlepší příklad z našeho webu je tedy jednoduše

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

... zpráva o zápisu ze zasedání předsedů W3C.

Témata a třídění podle tématu

O tomto nebezpečí se budu věnovat podrobněji, protože je to jedna z věcí, které je nejtěžší se vyhnout. Témata obvykle končí v URI, když své dokumenty kategorizujete podle práce, kterou vykonávají. Toto členění se ale časem změní. Názvy oblastí se změní. Ve W3C jsme chtěli změnit MarkUP na Markup a poté na HTML, aby odrážel skutečný obsah sekce. Navíc často existuje plochý jmenný prostor. Jste si jisti, že za 100 let nebudete chtít nic znovu použít? V našem krátkém životě jsme již chtěli znovu použít například "Historie" a "Style Sheets".

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. Jde o skvělé střednědobé řešení, ale z dlouhodobého hlediska má vážné nedostatky.

Část důvodu spočívá ve filozofii významu. Každý termín v jazyce je potenciálním cílem pro shlukování a každý člověk může mít jinou představu o tom, co to znamená. Vzhledem k tomu, že vztahy mezi entitami připomínají spíše web než strom, mohou i ti, kteří s webem souhlasí, zvolit jinou reprezentaci stromu. Toto jsou mé (často opakované) obecné postřehy o nebezpečích hierarchické klasifikace jako obecného řešení.

Ve skutečnosti, když použijete název tématu v URI, zavazujete se k nějaké klasifikaci. Možná v budoucnu dáte přednost jiné možnosti. URI pak bude náchylné k porušení.

Důvod pro použití předmětové oblasti jako součásti URI je ten, že odpovědnost za podsekce prostoru URI je obvykle delegována, a pak potřebujete název organizačního orgánu – oddělení, skupiny nebo cokoli jiného – který je za tento podprostor zodpovědný. Jedná se o vazbu URI na organizační strukturu. Obvykle je to bezpečné pouze v případě, že je další (levé) URI chráněno datem: 1998/pics může pro váš server znamenat „to, co jsme mysleli v roce 1998 s obrázky“, spíše než „co jsme v roce 1998 udělali s tím, čemu nyní říkáme obrázky“.

Nezapomeňte na název domény

Pamatujte, že to platí nejen pro cestu v URI, ale také pro název serveru. Pokud máte samostatné servery pro různé věci, pamatujte, ž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 na software, který dnes používáme“ jsou názvy domén „cgi.pathfinder.com“, „secure“, „lists.w3.org“. Jsou navrženy tak, aby usnadnily správu serveru. Bez ohledu na to, zda doména představuje divizi ve vaší společnosti, stav dokumentu, úroveň přístupu nebo úroveň zabezpečení, buďte velmi, velmi opatrní, než použijete více než jeden název domény pro více typů dokumentů. Pamatujte, že můžete skrýt více webových serverů do jednoho viditelného webového serveru pomocí přesměrování a proxy.

A také přemýšlejte o názvu své domény. Nechcete být označováni jako soap.com poté, co změníte produktovou řadu a přestanete vyrábět mýdlo (Omlouváme se tomu, kdo v tuto chvíli vlastní soap.com).

Závěr

Uchovat URI na 2, 20, 200 nebo dokonce 2000 let samozřejmě není tak snadné, jak se zdá. Na celém internetu však webmasteři dělají rozhodnutí, která jim tento úkol do budoucna opravdu ztěžují. Často je to proto, že používají nástroje, jejichž úkolem je prezentovat nejlepší stránky pouze v tuto chvíli – a nikdo neposoudil, co bude s odkazy, až se vše změní. Zde však jde o to, že mnoho, mnoho věcí se může 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 vytvoříte.

Viz také:

Přírůstky

Jak odstranit přípony souborů...

...z URI na aktuálním souborovém webovém serveru?

Pokud používáte například Apache, můžete jej nakonfigurovat tak, aby vyjednával obsah. Uložte příponu souboru (např. .png) do souboru (např. mydog.png), ale můžete odkazovat na webový zdroj i bez něj. Apache poté zkontroluje adresář pro všechny soubory s tímto názvem a libovolnou příponou a může vybrat ten nejlepší ze sady (například GIF a PNG). A není potřeba ukládat různé typy souborů do různých adresářů, ve skutečnosti shoda obsahu nebude fungovat, pokud to uděláte.

  • Nastavte svůj server pro vyjednávání obsahu
  • Vždy odkazujte na URI bez přípony

Odkazy s rozšířeními budou i nadále fungovat, ale zabrání vašemu serveru ve výběru nejlepšího formátu dostupného v současnosti i v budoucnu.

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

Samozřejmě, pokud píšete svůj vlastní webový server, je dobré použít databázi k navázání trvalých identifikátorů na jejich aktuální podobu, i když pozor na neomezený růst databáze.

The Board of Shame – Příběh 1: Kanál 7

Během roku 1999 jsem na stránce sledoval uzavření škol kvůli sněhu http://www.whdh.com/stormforce/closings.shtml. Nečekejte, až se informace objeví ve spodní části televizní obrazovky! Odkazoval jsem na něj ze své domovské stránky. Přichází první velká sněhová bouře roku 2000 a já koukám na stránku. Je tam napsáno:,

- Do.
Momentálně není nic uzavřeno. V případě varování před počasím se prosím vraťte.

Nemůže to být tak silná bouřka. Je vtipné, že chybí datum. Pokud však přejdete na hlavní stránku webu, zobrazí se velké tlačítko „Uzavřené š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 získávání seznamu - ale nepotřebovali měnit URI.

Board of Shame – Příběh 2: Microsoft Netmeeting

S rostoucí závislostí na internetu přišel chytrý nápad, že by do aplikací mohly být vloženy odkazy na web výrobce. Toto bylo hodně používáno a zneužíváno, ale nemůžete změnit URL. Zrovna nedávno jsem zkusil odkaz z klienta Microsoft Netmeeting 2/something v nabídce Help/Microsoft on the Web/Free things a obdržel jsem chybu 404 – nebyla nalezena žádná odpověď ze serveru. Možná už je to opravené...

© 1998 Tim BL

Historická poznámka: Na konci 20. století, kdy toto bylo napsáno, bylo „cool“ přídomek uznání, zejména mezi mladými lidmi, označující módnost, kvalitu nebo přiměřenost. Ve spěchu byla cesta URI často zvolena pro „chladnost“ spíše než pro užitečnost nebo trvanlivost. Tento příspěvek je pokusem přesměrovat energii za hledáním cool.

Zdroj: www.habr.com

Přidat komentář