Автор: Сър Тим Бърнърс-Лий, изобретател на URI, URL адреси, HTTP, HTML и World Wide Web и настоящ ръководител на 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

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

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

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

• Име на автора. Авторството може да се промени с появата на нови версии. Хората напускат организациите и предават нещата на други.
• Нещо. Много е трудно. В началото винаги изглежда добре, но се променя учудващо бързо. Ще говоря повече за това по-долу.
• статус. Директории като "стари", "чернови" и така нататък, да не говорим за "най-нови" и "готини", се появяват във всички файлови системи. Документите променят статуса - в противен случай няма да има смисъл да създавате чернови. Последната версия на документ се нуждае от постоянен идентификатор, независимо от неговия статус. Съхранявайте статуса извън името.
• Достъп. В W3C сме разделили сайта на секции за служители, членове и обществеността. Това звучи добре, но разбира се, документите започват като екипни идеи от персонала, обсъждат се с членовете и след това стават обществено достояние. Би било наистина жалко, ако всеки път, когато даден документ бъде отворен за по-широко обсъждане, всички стари връзки към него се развалят! Сега преминаваме към прост код за дата.
• Разширение на файл. Много често срещано явление. "cgi", дори ".html" ще се промени в бъдеще. Може да не използвате HTML за тази страница от 20 години, но днешните връзки към нея все още трябва да работят. Каноничните връзки на сайта на 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 г. със снимки“, а не „какво направихме през 1998 г. с това, което сега наричаме снимки“.

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

Не забравяйте, че това се отнася не само за пътя в 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: Канал 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 в менюто Web/Free stuff и получих грешка 404 - не беше намерен отговор от сървъра. Може би вече са го оправили...

© 1998 Тим БЛ

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

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