Аўтар - сэр Цім Бернерс-Лі, вынаходнік 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 у дадзены момант).

Заключэнне

Захаванне 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 на Web/Free stuff атрымаў памылку 404 — не знойдзены адказ ад сервера. Можа, ужо адрамантавалі…

© 1998 Tim BL

Гістарычная нататка: у канцы 20-га стагоддзя, калі гэта напісана, «крута» была эпітэтам адабрэння, асабліва сярод моладзі, які паказвае на моднасць, якасць або дарэчнасць. У спешцы шлях URI часта выбіралі з "крутасці", а не карыснасці ці даўгавечнасці. Гэтая нататка - спроба перанакіраваць энергію, якая стаіць за пошукам крутасці.

Крыніца: habr.com