Автор — сър Тим Бернерс-Ли, изобретател на URI, URL, HTTP, HTML и Световната мрежа, настоящият ръководител на W3C. Статията е написана през 1998 година.

Кой URI може да се счита за «култов»?
Такъв, който не се променя.
Как се променят URI?
URI не се променят: те са променяни от хора.

По принцип хората нямат причина да променят URI (или да спират поддръжката на документи), но на практика има милиони.

Теоретично, номиналният собственик на домейн имам действително владее домейна и следователно всички URI в него. Освен несъстоятелност, нищо не пречи на собственика на домейна да запази името. И теоретично, пространството на URI под вашия домейн е напълно под ваш контрол, така че можете да го направите толкова стабилно, колкото искате. В значителна степен единствената основателна причина за изчезването на документ от интернет е, че компанията, притежаваща домейна, е фалирала или вече не може да си позволи поддръжката на сървъра. Защо тогава в света има толкова много счупени връзки? Отчасти това е просто липса на предвидливост. Ето някои от причините, които може да чуете:

Просто преорганизирахме сайта, за да го направим по-добър.

Наистина ли смятате, че старите URI не могат да работят повече? Ако е така, вие много лошо сте ги избрали. Помислете за това, дали новите да останат след следващия редизайн.

Имаме толкова много материал, че не можем да следим какво е остаряло, какво е поверително и какво е все още актуално, затова помислихме, че е по-добре просто да изключим всичко това.

Мога само да съжалявам. W3C премина през период, в който трябваше внимателно да преглеждаме архивните материали за поверителност, преди да ги направим публични. Решението трябва да бъде обмислено предварително — уверете се, че записвате за всеки документ приемлив кръг читатели, дата на създаване и, по възможност, срок на валидност. Запазете тези метаданни.

Е, открихме, че трябва да преместим файловете…

Това е едно от най-жалките оправдания. Мнозина не знаят, че уеб сървърите ви позволяват да управлявате връзката между URI на обекта и действителното му местоположение в файловата система. Представете си пространството на URI като абстрактно пространство, перфектно организирано. След това направете отразяване на всяка реалност, която всъщност използвате, за да го реализирате. След това съобщете за това на уеб сървъра. Можете дори да напишете фрагмент от своя сървър, за да направите всичко както трябва.

Джон вече не поддържа този файл, сега това прави Джейн.

Имало ли е името на Джон в URI? Не, просто файлът се е намирал в неговата директория? А, ясно.

По-рано използвахме за това CGI-скрипт, а сега използваме бинарна програма.

Съществува луда идея, че страниците, създадени от скриптове, трябва да се намират в областта "cgibin" или "cgi". Това разкрива механизма на това как стартирате уеб сървъра си. Мените механизма (дори запазвайки съдържанието) и о, не — всичките ви URI се променят.

Да вземем, например, Националния научен фонд (NSF):

Онлайн-документи на NSF

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

Първата страница за започване на преглед на документите явно няма да остане такава след няколко години. cgi-bin, oldbrowse и pl — всичко това дава частици информация за как-правим-нещата-сега. Ако обаче използвате страницата за търсене на документ, получавате също толкова лош резултат на първо място:

Доклад на работната група по криптология и теория на кодирането

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

за индексната страница на документа, макар самият HTML-документ да изглежда много по-добре:

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

Тук заглавието pubs/1998 ще даде на всеки бъдещ архивен сервис добър ключ за разбиране какъв е действал старият модел на класификация на документи от 1998 г. Въпреки че през 2098 г. номерата на документите могат да изглеждат различно, мога да си представя, че този URI все още ще бъде валиден и той няма да пречи на NSF или на която и да е друга организация, която ще поддържа архива.

Не мислех, че URL адресите трябва да са постоянни — имаше и URN.

Вероятно, това е един от най-лошите странични ефекти на обсъждането на URN. Някои смятат, че заради изследванията относно по-постоянното пространство на имената, те могат небрежно да се отнасят към висящите линкове, тъй като „URN ще реши всичко това“. Ако сте един от тези хора, позволете да ви разочаровам.

Повечето URN схеми, които съм виждал, изглеждат като идентификатор на авторитет, последван от дата и низ, който избирате, или просто низ, който избирате. Това е много сходно с HTTP URI. С други думи, ако смятате, че вашата организация ще може да създава дългосрочни URN, то докажете това сега, като ги използвате за вашите HTTP URI. В самия HTTP няма нищо, което да направи вашия URI нестабилен. Само вашата организация. Създайте база данни, която асоциира URN документа с настоящото име на файла, и позволете на уеб сървъра да я използва за фактическо извличане на файловете.

Ако стигнахте до този момент, то ако нямате време, пари и връзки, за да разработите някакъв софтуер, можете да заявите следното оправдание:

Искахме, но просто нямаме нужните инструменти.

На това може да се съчувства. Напълно се съгласих. Това, което трябва да направите, е да накарате уеб сървъра моментално да обработи постоянния URI и да върне файла, независимо къде се съхранява в момента във вашата текуща луда файлова система. Искате да съхранявате всички URI в файл за проверка и постоянно да актуализирате базата данни. Искате да запазите отношенията между различните версии и преводи на един и същ документ, както и да запазите независим запис на контролна сума, за да осигурите защита срещу повреждане на файла поради случайна грешка. А уеб сървърите просто не идват с тези функции от кутията. Когато искате да създадете нов документ, вашият редактор ви моли да зададете URI.

Нужна ви е способността да променяте собствеността, достъпа до документа, ниво на сигурност на архивно ниво и други в пространството на URI, без да променяте URI.

Всичко е твърде лошо. Но ние ще поправим ситуацията. В W3C използваме функционалността на Jigedit (сървър Jigsaw за редактиране), който следи версиите, и експериментираме със скриптове за създаване на документи. Ако разработвате инструменти, сървъри и клиенти, обърнете внимание на този проблем!

Това оправдание важи и за много страници на W3C, включително тази: така че правете това, което казвам, а не това, което правя.

Защо това трябва да ме интересува?

Когато променяте URI на сървъра си, никога не можете напълно да кажете на кого ще бъдат линковете към стария URI. Това могат да бъдат линкове от обикновени уеб страници. Записвания за вашата страница. URI е могъл да бъде написан на полето на писмо до приятел.

Когато някой кликне на линк и той не работи, той обикновено губи доверие в собственика на сървъра. Той също е разочарован - емоционално и реално от невъзможността да постигне целта си.

Много хора постоянно се оплакват от неработещи линкове и се надявам, че щетите са очевидни. Надявам се също, че е очевидно репутационното увреждане на поддържащия сървъра, където документът е изчезнал.

Какво да правя? Дизайн на URI.

Това е задължение на уебмастъра - да проектира URI, които ще могат да се използват след 2 години, след 20 години и след 200 години. За това са нужни обмисленост, организираност и целеустремленост.

URI се променят, ако в тях се променя някаква информация. Много е важно как ги проектирате. (Какво, дизайн на URI? Трябва да проектирам URI? Да, трябва да помислите за това). Проектирането основно означава да няма информация в URI.

Дата на създаване на документа - дата на издаване на URI - е нещо, което никога не се променя. Тя е много полезна за разделяне на исканията, които използват новата система, от тези, които използват старата система. Добре е да започнете URI с нея. Ако има дата на документа, дори и документът да е актуален в бъдеще, това е добро начало.

Единственото изключение е страницата, която умишлено е «последната» версия, например, за цялата организация или голяма нейна част.

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

Това е последната колона на Money Daily в списание Money. Основната причина, поради която в този URI не е необходима дата, е, че няма причина да се запазва URI, което ще надживее списанието. Понятието Money Daily ще изчезне, когато изчезне Money. Ако искате да се позовете на съдържанието, трябва да се позовете на него отделно в архивите:

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

(Изглежда добре. Предполага, че "money" ще означава същото през целия живот на pathfinder.com. Има дублиране на "98" и ненужен ".html", но в противен случай изглежда като силен URI.

Какво да оставим настрана

Всичко! Освен датата на създаване, поставяйки всяка информация в URI, по един или друг начин, се навивате на неприятности.

Името на автора. Авторството може да се променя с появата на нови версии. Хората напускат организации и предават нещата на други.
Предмет. Това е много сложно. В началото винаги изглежда добре, но се променя удивително бързо. Ще разкажа повече за това по-долу.
Статус. Каталози като „стар“, „чернова“ и така нататък, да не говорим за „последен“ и „готин“, се появяват във всички файлови системи. Документите променят статуса си — иначе нямаше да има смисъл да се създават чернови. Последната версия на документа се нуждае от постоянен идентификатор, независимо от статуса му. Дръжте статуса извън името.
Достъп. В W3C разделихме сайта на секции за служители, членове и публика. Това звучи добре, но, разбира се, документите започват като идейни предложения на служителите, обсъждат се с членовете и след това стават достояние на обществеността. Наистина е досадно, ако всеки път, когато някой документ се отваря за по-широко обсъждане, всички стари връзки към него се чупят! Сега преминаваме към прост код на дата.
Разширение на файла. Много разпространен феномен. "cgi", дори ".html" ще се променят в бъдеще. Може би след 20 години няма да използвате HTML за тази страница, но днешните връзки към нея все още трябва да работят. Каноничните връзки на сайта W3C не използват разширение (как се прави).
Програмни механизми. В URI търсете "cgi", "exec" и други термини, които викат „погледнете какъв софтуер използваме“. Някой иска ли да посвети целия си живот на Perl CGI скриптове? Не? Тогава премахнете разширението .pl. Прочетете ръководството на сървъра как да го направите.
Име на диска. Хайде! Но съм виждал такова нещо.

Така че, най-добрият пример от нашия сайт е просто

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

… доклад за протокола на заседанията на председателите на W3C.

Темите и класификация по теми

Ще говоря по-дълго за тази опасност, тъй като това е едно от нещата, които най-много трудно може да се избегнат. Като правило темите попадат в URI, когато класифицирате документите си според извършената работа. Но тази разбивка ще се промени с времето. Имената на областите ще се променят. В W3C искахме да променим MarkUP на Markup, а след това на HTML, за да отразим действителното съдържание на раздела. Освен това, често тук има плоско пространство с имена. След 100 години сигурно няма да искате да повтаряте нищо? В нашия кратък живот вече искахме да повторим „История“ и „Таблици с стилове“, например.

Това е примамлив начин за организация на уебсайта – и наистина привлекателен начин за организиране на каквото и да е, включително цялата Мрежа. Това е отлично краткосрочно решение, но има сериозни недостатъци в дългосрочен план.

Отчасти причините се крият в философията на смисъла. Всеки термин в езика е потенциален обект на кластеризация и всеки човек може да има различно разбиране за това, какво означава. Тъй като отношенията между субектите са по-скоро подобни на паяжина, отколкото на дърво, дори и тези, които са съгласни с паяжината, могат да изберат различно представяне на дървото. Това са моите (често повторяеми) общи забележки относно опасностите от херархичната класификация като общо решение.

Всъщност, когато използвате името на темата в URI, вие се обвързвате с определена класификация. В бъдеще може да предпочетете друг вариант. Тогава URI ще бъде подложен на нарушаване.

Причината да използвате тематичната област като част от URI е, че отговорността за подсекции на URI пространството обикновено се делегира, и тогава имате нужда от името на организационния орган – подразделение, група или нещо друго, което носи отговорност за тази подпространство. Това е обвързване на URI с организационната структура. Обикновено е безопасно само когато по-нататък (вляво) URI е защитен с дата: 1998/pics може да означава за вашия сървър „това, което искахме да кажем през 1998 година под pics“, а не „това, което през 1998 година направихме с това, което сега наричаме pics“.

Не забравяйте домейн името

Помнете, че това не се отнася само за пътя в URI, но и за името на сървъра. Ако имате отделни сървъри за различни неща, помнете, че това разделение ще бъде невъзможно да се промени, без да унищожите много линкове. Някои класически грешки тип „вижте какво софтуер използваме днес“ – домейни като "cgi.pathfinder.com", "secure", "lists.w3.org". Те са създадени, за да улеснят администрирането на сървъри. Независимо от това, дали домейна представя някое подразделение във вашата компания, статус на документа, ниво на достъп или ниво на сигурност, бъдете много, много внимателни, преди да използвате повече от едно домейн име за различни видове документи. Помнете, че можете да скриете много уеб сървъри в един видим уеб сървър, използвайки пренасочване и прокси.

Да, и още помислете за вашето домейн име. Не искате да ви цитират като soap.com, след като смените продуктовата си линия и спрете да произвеждате сапун (Извинявайте на притежателя на soap.com в момента).

Заключение

Запазването на URI за 2, 20, 200 или дори 2000 години очевидно не е толкова просто, колкото изглежда. Въпреки това, из целия интернет уебмастърите взимат решения, които наистина затрудняват тази задача в бъдеще. Често това се случва, защото те използват инструменти, чиято задача е да представят най-добрия сайт само в този момент — и никой не е оценил какво ще се случи с линковете, когато всичко се промени. Въпреки това, смисълът тук е, че много, наистина много може да се променят, и вашите URI могат и трябва да останат същите. Това е възможно само тогава, когато мислите за начина, по който ги създавате.

Вижте също:

Тирадата на Якоб Нилсен по същата тема

Разширения

Как да премахнете разширенията на файловете…

...от URI в текущия уеб сървър, базиран на файлове?

Ако използвате, например, Apache, можете да го настроите да съвпада с съдържанието. Запазвате разширението на файла (например, .png) в файла (например, mydog.png), но можете да се позовавате на уеб ресурса и без него. След това Apache проверява директорията за наличието на всички файлове с това име и всяко разширение и може да избере най-доброто от набора (например, GIF и PNG). И не е необходимо да поставяте различни типове файлове в различни директории, в действителност, съгласуването на съдържанието няма да работи, ако направите това.

Настройте сървъра си за съгласуване на съдържанието
Винаги правете връзки към URI без разширение

Връзките с разширения все още ще работят, но няма да позволят на сървъра ви да избере най-добрия наличен в момента и бъдещите формати.

(Всъщност, mydog, mydog.png и mydog.gif — валидни уеб ресурси, mydog — това е ресурс с универсален тип съдържание, а mydog.png и mydog.gif — ресурси с конкретен тип съдържание).

Разбира се, ако пишете собствен уеб сървър, е добре да използвате база данни за свързване на постоянни идентификатори с актуалната им форма, макар и да внимавате с неограничения растеж на БД.

Доска на срама — История 1: Channel 7

През 1999 г. следих затварянето на училища заради сняг по страницата http://www.whdh.com/stormforce/closings.shtml. Не бива да чакам информацията да се появи в долната част на телевизионния екран! Поставих линк на нея от моята домашна страница. Настъпва първият голям снеговалеж през 2000 г. и проверявам страницата. Там пише:

— Към момента.
В момента нищо не е затворено. Моля, проверявайте отново в случай на прогнози за времето.

Не може да бъде, такъв силен снеговалеж. Забавно, че датата липсва. Но ако отидете на основната страница на сайта, там ще има голям бутон „Затворени училища“, който води до страница http://www.whdh.com/stormforce/ с дълъг списък на затворени училища.

Може би са променили системата за получаване на списъка — но не е било необходимо да променят URI.

Доска на срама — История 2: Microsoft Netmeeting

С нарастващата зависимост от интернет дойде и умната идея, че в приложенията може да се внедряват линкове към уебсайта на производителя. Това често е било използвано и злоупотребявано, но — URL не може да се променя. Преди дни пробвах линк от клиента Microsoft Netmeeting 2/something в менюто Help/Microsoft on the Web/Free stuff и получих грешка 404 — не е намерен отговор от сървера. Може би вече е поправено...

Историческо бележка: в края на 20-ти век, когато това беше написано, "яко" беше епитет на одобрение, особено сред младежта, сочещ на модност, качество или уместност. В бързината, пътят URI често се избираше заради "яхо", а не за ползваемост или дълготрайност. Тази бележка е опит да се пренасочи енергията, стояща зад търсенето на яко.

Източник: habr.com