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

Бул жерде пабдар/1998 аталышы келечектеги ар кандай архивдик кызматка 1998-жылдагы эски документти классификациялоо схемасы иштеп жаткандыгы жөнүндө жакшы маалымат берет. Документтин номерлери 2098-жылы башкача көрүнүшү мүмкүн болсо да, мен бул URI дагы эле жарактуу болуп, NSF же архивди сактай турган башка уюмга тоскоол болбойт деп ойлойт элем.

Мен URL'дер туруктуу болушу керек деп ойлогон эмесмин - URNs бар.

Бул, балким, URN дебаттын эң жаман терс таасирлеринин бири. Кээ бир адамдар бир кыйла туруктуу аталыштар мейкиндигин изилдөөдөн улам, алар илинип турган шилтемелерге көңүл бурушу мүмкүн деп ойлошот, анткени "URNs мунун баарын оңдойт". Эгер сиз ушул адамдардын бири болсоңуз, анда мен сиздин көңүлүңүздү калтырууга уруксат этиңиз.

Мен көргөн URN схемаларынын көбү авторитеттин идентификаторуна окшош, андан кийин же сиз тандаган дата жана сап, же жөн эле сиз тандаган сап. Бул HTTP URIга абдан окшош. Башкача айтканда, эгер сиз уюмуңуз узак мөөнөттүү URN түзө алат деп ойлосоңуз, анда аларды HTTP URI'лериңиз үчүн колдонуу менен азыр далилдеңиз. HTTP өзүндө сиздин URI туруксуз кылган эч нерсе жок. Сиздин уюм гана. Документтин URN файлын учурдагы файл атына окшоштурган маалымат базасын түзүңүз жана веб-сервер аны файлдарды чындап алуу үчүн колдонсун.

Эгер сиз ушул деңгээлге жеткен болсоңуз, кандайдыр бир программалык камсыздоону иштеп чыгууга убакытыңыз, акчаңыз жана байланыштарыңыз жок болсо, анда төмөнкү шылтоону айта аласыз:

Биз кааладык, бирок бизде туура шаймандар жок.

Бирок буга боор ооруса болот. Мен толугу менен кошулам. Сиз эмне кылышыңыз керек, веб-серверди токтоосуз URI талдоосуна мажбурлоо жана файлды учурдагы жинди файл тутумуңузда сакталган бардык жерде кайтаруу. Сиз бардык URI'лерди файлда чек катары сактап, маалымат базасын ар дайым жаңыртып тургуңуз келет. Сиз бир эле документтин ар кандай версиялары менен котормолорунун ортосундагы байланышты сактап калгыңыз келет, ошондой эле файл кокустан ката менен бузулуп калбасын камсыз кылуу үчүн көз карандысыз текшерүү суммасынын эсебин жүргүзгүңүз келет. Жана веб-серверлер бул өзгөчөлүктөр менен кутудан чыкпайт. Жаңы документ түзгүңүз келгенде, редакторуңуз сизден URI көрсөтүүнү суранат.

URI мейкиндигинде URI мейкиндигинде менчик укугун, документке кирүү мүмкүнчүлүгүн, архив деңгээлинин коопсуздугун ж.б. өзгөртө алышыңыз керек.

Мунун баары өтө жаман. Бирок биз абалды оңдойбуз. W3Cде биз версияларга көз салган Jigedit (Jigsaw түзөтүү сервери) функциясын колдонобуз жана документ түзүү скрипттери менен эксперимент жасайбыз. Эгер сиз куралдарды, серверлерди жана кардарларды иштеп чыксаңыз, бул көйгөйгө көңүл буруңуз!

Бул шылтоо көптөгөн 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ти 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 жылга чейин сактоо, албетте, көрүнгөндөй оңой эмес. Бирок, бардык Интернет боюнча, Webmasters келечекте өздөрү үчүн бул милдетти чындап эле кыйын кылып жаткан чечимдерди кабыл алууда. Көбүнчө мунун себеби, алар эң мыкты сайтты азыркы учурда гана көрсөтүү болгон куралдарды колдонушат - жана баары өзгөргөндө шилтемелер эмне болорун эч ким эсептей элек. Бирок, бул жерде көп нерсе өзгөрүшү мүмкүн жана сиздин URI'ларыңыз ошол эле бойдон калышы мүмкүн жана болушу керек. Бул сиз аларды кантип жаратканыңыз жөнүндө ойлонгондо гана мүмкүн болот.

Кара .:

• Якоб Нильсендин ушул эле темадагы тирадасы

Supplements

Файл кеңейтүүлөрүн кантип алып салуу керек ...

...учурдагы файлга негизделген веб-сервердеги 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/бир нерсе кардарынын Шилтемесин Желе/Акысыз нерселер менюсундагы Жардам/Microsoft аркылуу сынап көрдүм жана 404 катасын алдым - серверден эч кандай жооп табылган жок. Балким, ал мурунтан эле оңдолгон ...

© 1998 Тим БЛ

Тарыхый эскертүү: 20-кылымдын аягында, бул жазылганда, "крутой" өзгөчө жаштардын модалуулугун, сапатын же ылайыктуулугун көрсөткөн жактыруунун эпитети болгон. Шашылыш менен, URI жолу көбүнчө пайдалуу же туруктуулук үчүн эмес, "салкындык" үчүн тандалган. Бул пост салкын издөөнүн артындагы энергияны кайра багыттоо аракети.

Source: www.habr.com