Автор: Сер Тим Бернерс-Ли, пронаоѓач на 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 што сум ги видел изгледаат како идентификатор на авторитет проследен со датум и низа што ќе ја изберете или само низа што ја избирате. Ова е многу слично на HTTP URI. Со други зборови, ако мислите дека вашата организација ќе биде способна да создава долготрајни URN, тогаш докажете го тоа сега користејќи ги за вашите HTTP URI. Нема ништо во самиот HTTP што го прави вашиот URI нестабилен. Само вашата организација. Направете база на податоци што го пресликува URN-то на документот со тековното име на датотеката и дозволете му на веб-серверот да ја користи за да ги преземе датотеките.

Ако сте стигнале до оваа точка, ако немате време, пари и врски да развиете некој софтвер, тогаш можете да го наведете следниот изговор:

Сакавме, но едноставно ги немаме соодветните алатки.

Но, можете да сочувствувате со ова. Потполно се согласувам. Она што треба да направите е да го принудите веб-серверот веднаш да го анализира постојаниот URI и да ја врати датотеката каде и да е моментално зачувана на вашиот сегашен луд датотечен систем. Сакате да ги зачувате сите URI во датотека како проверка и да ја одржувате базата на податоци постојано ажурирана. Сакате да ја зачувате врската помеѓу различни верзии и преводи на истиот документ, а исто така да одржувате независен запис за проверка за да се осигурате дека датотеката не е оштетена од случајна грешка. И веб-серверите едноставно не излегуваат од кутијата со овие карактеристики. Кога сакате да креирате нов документ, вашиот уредник бара од вас да наведете URI.

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

Сето тоа е премногу лошо. Но, ние ќе ја поправиме ситуацијата. На W3C, ја користиме функционалноста Jigedit (сервер за уредување сложувалка) која ги следи верзиите и експериментираме со скрипти за креирање документи. Ако развивате алатки, сервери и клиенти, обрнете внимание на овој проблем!

Овој изговор важи и за многу страници на 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 ќе исчезне кога ќе исчезнат парите. Ако сакате да се поврзете до содржината, треба да се поврзете до неа посебно во архивите:

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/слики може да значи за вашиот сервер „што мислевме во 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.

Board of Shame - Приказна 2: Microsoft Netmeeting

Со зголемената зависност од Интернет, дојде паметна идеја дека линковите до веб-страницата на производителот може да се вметнат во апликациите. Ова е многу користено и злоупотребувано, но не можете да го промените URL-то. Баш пред некој ден пробав врска од Microsoft Netmeeting 2/something клиентот во Help/Microsoft on the Web/Free stuff менито и добив грешка 404 - не беше пронајден одговор од серверот. Можеби веќе е поправено...

© 1998 Тим Б.Л

Историска белешка: Кон крајот на 20 век, кога ова беше напишано, „кул“ беше епитет на одобрување, особено кај младите луѓе, што укажува на модерност, квалитет или соодветност. Набрзина, URI патеката честопати беше избрана за „кулина“ наместо за корисност или издржливост. Овој пост е обид да се пренасочи енергијата зад потрагата по кул.

Извор: www.habr.com