Авторы: сэр Тим Бернерс-Ли, 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

Мұнда pub/1998 тақырыбы кез келген болашақ мұрағаттық қызметке 1998 жылғы ескі құжатты жіктеу схемасы әрекет ететіні туралы жақсы мәлімет береді. 2098 жылы құжат нөмірлері басқаша көрінуі мүмкін болса да, мен бұл URI әлі де жарамды болады және NSF немесе мұрағатты жүргізетін кез келген басқа ұйымға кедергі жасамайды деп ойлаймын.

Мен URL мекенжайлары тұрақты болуы керек деп ойламадым - URN бар.

Бұл URN дебатының ең нашар жанама әсерлерінің бірі болуы мүмкін. Кейбір адамдар тұрақты аттар кеңістігін зерттеуге байланысты олар салбырап тұрған сілтемелерге немқұрайлы қарауы мүмкін деп ойлайды, себебі «URN мұның бәрін түзетеді». Егер сіз осы адамдардың бірі болсаңыз, онда сізді көңіліңізді қалдыруға рұқсат етіңіз.

Мен көрген URN схемаларының көпшілігі өкілеттік идентификаторына ұқсайды, одан кейін сіз таңдаған күн мен жол немесе сіз таңдаған жол ғана. Бұл HTTP URI-ге өте ұқсас. Басқаша айтқанда, ұйымыңыз ұзақ мерзімді URN жасай алады деп ойласаңыз, оларды HTTP URI мекенжайлары үшін пайдалану арқылы қазір дәлелдеңіз. HTTP-де URI-ді тұрақсыз ететін ештеңе жоқ. Тек сіздің ұйымыңыз. URN құжатын ағымдағы файл атауымен салыстыратын дерекқорды жасаңыз және веб-серверге файлдарды нақты шығарып алу үшін оны пайдалануға рұқсат етіңіз.

Егер сіз осы деңгейге жеткен болсаңыз, кейбір бағдарламалық жасақтаманы әзірлеуге уақытыңыз, ақшаңыз және байланысыңыз болмаса, келесі ақтауды айта аласыз:

Біз қаладық, бірақ бізде дұрыс құралдар жоқ.

Бірақ сіз бұған түсіністікпен қарай аласыз. Мен толықтай келісемін. Сізге не істеу керек - бұл веб-серверді тұрақты URI мекенжайын лезде талдауға және файлды ағымдағы ессіз файлдық жүйеде сақталған жерде қайтаруға мәжбүрлеу. Барлық URI мекенжайларын файлда тексеру ретінде сақтағыңыз келеді және дерекқорды әрқашан жаңартып отырыңыз. Бір құжаттың әртүрлі нұсқалары мен аудармалары арасындағы қатынасты сақтағыңыз келеді, сонымен қатар файл кездейсоқ қатеден бүлінбегеніне көз жеткізу үшін тәуелсіз бақылау сомасы жазбасын жүргізгіңіз келеді. Ал веб-серверлер бұл мүмкіндіктермен қораптан шықпайды. Жаңа құжат жасағыңыз келгенде, редактор сізден URI мекенжайын көрсетуді сұрайды.

URI кеңістігінде меншік құқығын, құжатқа қол жеткізуді, мұрағат деңгейінің қауіпсіздігін және т.б. өзгерте алуыңыз қажет.

Мұның бәрі тым нашар. Бірақ біз жағдайды түзетеміз. W3C жүйесінде біз нұсқаларды қадағалайтын Jigedit (Джигсо өңдеу сервері) функциясын қолданамыз және құжат жасау сценарийлерімен тәжірибе жасаймыз. Егер сіз құралдарды, серверлерді және клиенттерді дамытсаңыз, осы мәселеге назар аударыңыз!

Бұл ақтаудың көптеген W3C беттеріне, соның ішінде мына беттерге де қатысты: сондықтан мен айтқандай емес, менің айтқанымды орындаңыз.

Мен неге қамқорлық жасауым керек?

Сервердегі URI мекенжайын өзгерткен кезде, ескі URI сілтемелері кімде болатынын ешқашан толық айта алмайсыз. Бұл кәдімгі веб-беттерден алынған сілтемелер болуы мүмкін. Парақшаңызды белгілеңіз. URI досыңызға хаттың шетіне шиыршықталған болуы мүмкін.

Біреу сілтемені орындаған кезде және ол бұзылса, олар әдетте сервер иесіне сенімін жоғалтады. Ол да мақсатына жете алмағандықтан эмоционалды да, физикалық тұрғыдан да көңілі күйзеледі.

Көптеген адамдар үзілген сілтемелер туралы үнемі шағымданады және мен зияны анық деп үміттенемін. Құжат жоғалған сервердің қызметшісінің беделіне нұқсан келтіретіні де анық деп үміттенемін.

Сонда мен не істеуім керек? URI дизайны

2 жылдан кейін, 20 жылдан кейін, 200 жылдан кейін пайдалануға болатын URI мекенжайларын бөлу веб-шебердің міндеті. Бұл ойлауды, ұйымшылдықты және табандылықты қажет етеді.

Егер олардағы кез келген ақпарат өзгерсе, URI өзгереді. Оларды қалай құрастырғаныңыз өте маңызды. (Не, URI дизайны? Маған URI дизайнын жасау керек пе? Иә, бұл туралы ойлану керек). Дизайн негізінен URI-де кез келген ақпаратты қалдыруды білдіреді.

Құжат жасалған күн - URI берілген күні - ешқашан өзгермейтін нәрсе. Бұл жаңа жүйені пайдаланатын сұрауларды ескі жүйені пайдаланатын сұрауларды бөлу үшін өте пайдалы. Бұл URI арқылы бастау үшін жақсы орын. Егер құжаттың күні болса, ол құжат болашақта өзекті болса да, бұл жақсы бастама.

Жалғыз ерекшелік - бұл әдейі «соңғы» нұсқасы, мысалы, бүкіл ұйым немесе оның үлкен бөлігі үшін.

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

Бұл Money журналындағы соңғы Money Daily бағанасы. Бұл 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 параметрін Белгілеуге, содан кейін 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/бір нәрсе клиентінің сілтемесін Web/Free stuff мәзіріндегі Анықтама/Microsoft ішінен қолданып көрдім және 404 қатесін алдым - серверден жауап табылмады. Мүмкін ол әлдеқашан жөнделген шығар...

© 1998 Тим Б.Л

Тарихи жазба: 20-шы ғасырдың соңында, бұл жазылған кезде, «салқын» әсіресе жастар арасында сәнділікті, сапаны немесе орындылықты көрсететін мақұлдау эпитеті болды. Асығыс кезінде URI жолы жиі пайдалылық немесе ұзақ мерзімділік үшін емес, «салқындық» үшін таңдалды. Бұл пост салқын іздеудің артындағы энергияны қайта бағыттау әрекеті.

Ақпарат көзі: www.habr.com