Muallif: Ser Tim Berners-Li, URI, URL manzillari, HTTP, HTML va World Wide Web ixtirochisi va W3Cning hozirgi rahbari. 1998 yilda yozilgan maqola

Qaysi URI "ajoyib" deb hisoblanadi?
O'zgarmaydigan biri.
URI qanday o'zgartiriladi?
URIlar o'zgarmaydi: odamlar ularni o'zgartiradilar.

Nazariy jihatdan, odamlarning URI-ni o'zgartirishi (yoki qo'llab-quvvatlovchi hujjatlarni to'xtatish) uchun hech qanday sabab yo'q, lekin amalda ularning millionlablari bor.

Nazariy jihatdan, domen nomlari maydonining nominal egasi aslida domen nomlari maydoniga va shuning uchun undagi barcha URI-larga egalik qiladi. To'lovga layoqatsizlikdan tashqari, hech narsa domen nomi egasiga nomni saqlab qolishiga to'sqinlik qilmaydi. Va nazariy jihatdan, domen nomingiz ostidagi URI maydoni butunlay sizning nazoratingiz ostida, shuning uchun uni xohlagancha barqaror qilishingiz mumkin. Hujjatning internetdan yo'qolishining deyarli yagona yaxshi sababi shundaki, domen nomiga ega bo'lgan kompaniya o'z faoliyatini to'xtatib qo'ygan yoki serverning ishlashini saqlab qola olmaydi. Xo'sh, nima uchun dunyoda etishmayotgan havolalar juda ko'p? Bularning ba'zilari shunchaki oldindan o'ylashning etishmasligi. Eshitishingiz mumkin bo'lgan ba'zi sabablar:

Biz shunchaki saytni yaxshiroq qilish uchun qayta tashkil qildik.

Sizningcha, eski URIlar endi ishlay olmaydimi? Agar shunday bo'lsa, unda siz ularni juda yomon tanlagansiz. Keyingi qayta dizayn uchun yangilarini saqlashni o'ylab ko'ring.

Bizda shu qadar ko'p narsalar borki, nima eskirgan, nima maxfiy va nimalar dolzarbligini kuzatib bo'lmaydi, shuning uchun hammasini o'chirib qo'yishni ma'qul deb topdik.

Men faqat hamdardlik bildira olaman. W3C arxiv materiallarini ommaga oshkor qilishdan oldin maxfiyligini sinchkovlik bilan ko'rib chiqishimiz kerak bo'lgan davrni boshdan kechirdi. Qarorni oldindan o'ylab ko'rish kerak - har bir hujjatda siz maqbul o'quvchilar soni, yaratilish sanasi va ideal holda amal qilish muddatini yozib olishingizga ishonch hosil qiling. Ushbu metama'lumotlarni saqlang.

Xo'sh, biz fayllarni ko'chirishimiz kerakligini aniqladik ...

Bu eng achinarli bahonalardan biridir. Ko'pchilik veb-serverlar ob'ektning URI manzili va uning fayl tizimidagi haqiqiy joylashuvi o'rtasidagi munosabatni boshqarish imkonini berishini bilishmaydi. URI maydonini mukammal tashkil etilgan mavhum makon sifatida tasavvur qiling. Keyin uni amalga oshirish uchun foydalanadigan haqiqatning xaritasini tuzing. Keyin bu haqda veb-serverga xabar bering. Siz hatto uni to'g'ri bajarish uchun o'z server parchangizni yozishingiz mumkin.

Jon endi bu faylni saqlamaydi, Jeyn endi saqlaydi.

URIda Jonning ismi bormi? Yo'q, fayl faqat uning katalogida bo'lganmi? Xo'sh, yaxshi.

Ilgari biz buning uchun CGI skriptidan foydalanganmiz, ammo hozir biz ikkilik dasturdan foydalanamiz.

Skriptlar tomonidan yaratilgan sahifalar "cgibin" yoki "cgi" maydonida joylashgan bo'lishi kerak degan aqldan ozgan fikr bor. Bu sizning veb-serveringizni qanday boshqarishingiz mexanikasini ochib beradi. Siz mexanizmni o'zgartirasiz (hatto kontentni saqlashda ham) va ey - barcha URI-laringiz o'zgaradi.

Misol uchun, Milliy fan fondini (NSF) olaylik:

NSF onlayn hujjatlari

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

Hujjatlarni ko'rishni boshlagan birinchi sahifa bir necha yil ichida o'zgarmasligi aniq. cgi-bin, oldbrowse и pl - bularning barchasi biz buni qanday qilishimiz haqida ma'lumot beradi. Agar siz hujjatni qidirish uchun sahifadan foydalansangiz, birinchi natija bir xil darajada yomon bo'ladi:

Kriptologiya va kodlash nazariyasi bo'yicha ishchi guruhining hisoboti

http://www.nsf.gov/cgi-bin/getpub?nsf9814

Hujjat indeksi sahifasi uchun html hujjatining o'zi ancha yaxshi ko'rinadi:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Bu erda publar/1998 sarlavhasi har qanday kelajakdagi arxiv xizmatiga 1998 yilgi hujjatlarni tasniflash sxemasi amalda ekanligi haqida yaxshi ma'lumot beradi. Hujjat raqamlari 2098 yilda boshqacha ko'rinishi mumkin bo'lsa-da, men ushbu URI hali ham amalda bo'lishini va NSF yoki arxivni saqlaydigan boshqa tashkilotga xalaqit bermasligini tasavvur qilaman.

Men URL manzillar doimiy bo'lishi kerak deb o'ylamagan edim - URNlar bor edi.

Bu, ehtimol, URN bahsining eng yomon yon ta'siridan biridir. Ba'zi odamlar doimiyroq nomlar maydonini o'rganish tufayli ular osilgan havolalarga beparvo bo'lishlari mumkin deb o'ylashadi, chunki "URNlar hammasini tuzatadi". Agar siz bu odamlardan bo'lsangiz, men sizni xafa qilishimga ruxsat bering.

Men ko'rgan ko'pgina URN sxemalari vakolat identifikatoriga o'xshaydi, undan keyin siz tanlagan sana va qator yoki siz tanlagan satr. Bu HTTP URI ga juda o'xshaydi. Boshqacha qilib aytadigan bo'lsak, agar tashkilotingiz uzoq muddatli URN-larni yaratishga qodir deb hisoblasangiz, ularni HTTP URI-lar uchun ishlatib, hozir buni isbotlang. HTTP-da sizning URI-ni beqaror qiladigan hech narsa yo'q. Faqat sizning tashkilotingiz. Hujjatning URN-ni joriy fayl nomi bilan taqqoslaydigan ma'lumotlar bazasini yarating va veb-serverdan fayllarni haqiqatda olish uchun foydalanishiga ruxsat bering.

Agar siz shu darajaga yetgan bo'lsangiz, ba'zi bir dasturiy ta'minotni ishlab chiqish uchun vaqtingiz, pulingiz va aloqangiz bo'lmasa, quyidagi bahonani aytishingiz mumkin:

Biz xohladik, lekin bizda to'g'ri vositalar yo'q.

Ammo siz bunga hamdard bo'lishingiz mumkin. Men butunlay roziman. Sizga kerak bo'lgan narsa veb-serverni doimiy URI-ni darhol tahlil qilishga majburlash va faylni hozirgi aqldan ozgan fayl tizimingizda saqlangan joyga qaytarishdir. Siz barcha URI'larni faylda chek sifatida saqlashni va ma'lumotlar bazasini har doim yangilab turishni xohlaysiz. Siz bir xil hujjatning turli versiyalari va tarjimalari o'rtasidagi munosabatni saqlab qolishni, shuningdek, fayl tasodifiy xato tufayli buzilmasligini ta'minlash uchun mustaqil nazorat summasini qayd qilishni xohlaysiz. Veb-serverlar esa bu xususiyatlar bilan qutidan chiqmaydi. Yangi hujjat yaratmoqchi bo'lganingizda, muharriringiz sizdan URI ko'rsatishingizni so'raydi.

URI maydonida egalik huquqini, hujjatga kirish huquqini, arxiv darajasi xavfsizligini va hokazolarni URI ni o'zgartirmasdan o'zgartirish imkoniyatiga ega bo'lishingiz kerak.

Hammasi juda yomon. Ammo biz vaziyatni to'g'irlaymiz. W3C da biz versiyalarni kuzatuvchi Jigedit (Jigsaw tahrirlash serveri) funksiyasidan foydalanamiz va hujjat yaratish skriptlari bilan tajriba o‘tkazamiz. Agar siz vositalar, serverlar va mijozlarni ishlab chiqsangiz, bu masalaga e'tibor bering!

Bu uzr ko'plab W3C sahifalariga, shu jumladan shu sahifaga ham tegishli: shuning uchun men aytganimdek emas, men aytgandek qiling.

Nega g'amxo'rlik qilishim kerak?

Serveringizdagi URI-ni o'zgartirganingizda, eski URI-ga kimning havolalari bo'lishini hech qachon to'liq ayta olmaysiz. Bu oddiy veb-sahifalardan havolalar bo'lishi mumkin. O'z sahifangizni belgilang. URI do'stingizga yozgan xatning chetiga chizilgan bo'lishi mumkin.

Kimdir havolaga ergashsa va u buzilgan bo'lsa, ular odatda server egasiga ishonchini yo'qotadilar. Bundan tashqari, u o'z maqsadiga erisha olmagani uchun ham ruhiy, ham jismonan hafsalasi pir bo'ladi.

Ko'p odamlar doimo buzilgan havolalar haqida shikoyat qiladilar va umid qilamanki, zarar aniq. Umid qilamanki, hujjat yo'qolgan serverning xizmat ko'rsatuvchisi obro'siga putur etkazganligi ham aniq.

Xo'sh, nima qilishim kerak? URI dizayni

2 yil, 20 yil, 200 yil ichida foydalanish mumkin bo'lgan URI-larni ajratish veb-ustaning mas'uliyatidir. Bu o'ychanlik, tashkilotchilik va qat'iyatni talab qiladi.

Agar ulardagi biron bir ma'lumot o'zgarsa, URIlar o'zgaradi. Ularni qanday loyihalash juda muhim. (Nima, URI dizayni? URIni loyihalashim kerakmi? Ha, bu haqda o'ylab ko'rishingiz kerak). Dizayn asosan URI-da har qanday ma'lumotni qoldirishni anglatadi.

Hujjat yaratilgan sana - URI berilgan sana - hech qachon o'zgarmaydigan narsa. Bu yangi tizimdan foydalanadigan so'rovlarni eski tizimdan foydalanadigan so'rovlarni ajratish uchun juda foydali. Bu URI bilan boshlash uchun yaxshi joy. Agar hujjatning sanasi ko'rsatilgan bo'lsa, hatto hujjat kelajakda tegishli bo'lsa ham, bu yaxshi boshlanishdir.

Faqatgina istisno - bu butun tashkilot yoki uning katta qismi uchun ataylab "so'nggi" versiya bo'lgan sahifa.

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

Bu Money jurnalidagi eng so'nggi Money Daily rukni. Ushbu URIda sana kerak emasligining asosiy sababi, jurnaldan uzoqroq bo'ladigan URIni saqlash uchun hech qanday sabab yo'qligidir. Pul yo'qolganda, Money Daily tushunchasi yo'qoladi. Agar siz kontentga havola qilmoqchi bo'lsangiz, uni arxivda alohida bog'lashingiz kerak:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(Yaxshi ko'rinadi. "Pul" pathfinder.com butun umri davomida bir xil ma'noni anglatadi, deb faraz qiladi. "98" dublikati va keraksiz ".html" mavjud, ammo aks holda kuchli URIga o'xshaydi.

Nimani chetga qoldirish kerak

Hammasi! Yaratilgan sanadan tashqari, har qanday ma'lumotni URIga qo'yish u yoki bu tarzda muammo tug'diradi.

muallifning ismi. Yangi versiyalar paydo bo'lishi bilan mualliflik o'zgarishi mumkin. Odamlar tashkilotlarni tark etib, narsalarni boshqalarga topshirishadi.
Mavzu. Bu juda qiyin. Avvaliga u har doim yaxshi ko'rinadi, lekin hayratlanarli darajada tez o'zgaradi. Bu haqda quyida ko‘proq gaplashaman.
Holat. "Eski", "qoralama" va shunga o'xshash kataloglar, "so'nggi" va "salqin" emas, balki barcha fayl tizimlarida paydo bo'ladi. Hujjatlar holatni o'zgartiradi - aks holda qoralama yaratishdan foyda bo'lmaydi. Hujjatning oxirgi versiyasi, uning holatidan qat'i nazar, doimiy identifikatorga muhtoj. Statusni nomdan uzoqroq tuting.
Kirish. W3C da biz saytni xodimlar, a'zolar va jamoatchilik uchun bo'limlarga ajratdik. Bu yaxshi eshitiladi, lekin, albatta, hujjatlar xodimlarning jamoaviy g'oyalari sifatida boshlanadi, a'zolar bilan muhokama qilinadi va keyin jamoatchilikka ma'lum bo'ladi. Hujjat har safar kengroq muhokama uchun ochilganda, unga barcha eski havolalar buzilib qolsa, haqiqatan ham uyat bo'lardi! Endi biz oddiy sana kodiga o'tamiz.
Fayl kengaytmasi. Juda keng tarqalgan hodisa. "cgi", hatto ".html" ham kelajakda o'zgaradi. Siz 20 yildan beri bu sahifa uchun HTML dan foydalanmayotgan boʻlishingiz mumkin, ammo bugungi havolalar hali ham ishlashi kerak. W3C saytidagi kanonik havolalar kengaytmadan foydalanmaydi (qanday amalga oshirilgan).
Dasturiy ta'minot mexanizmlari. URI-da "cgi", "exec" va "qanday dasturiy ta'minotdan foydalanayotganimizga qarang" deb qichqiradigan boshqa atamalarni qidiring. Kimdir butun hayotini Perl CGI skriptlarini yozishga sarflashni xohlaydimi? Yo'qmi? Keyin .pl kengaytmasini olib tashlang. Buni qanday qilish haqida server qo'llanmasini o'qing.
Disk nomi. Qo'ysangchi; qani endi! Lekin men buni ko'rganman.

Shunday qilib, bizning saytimizdagi eng yaxshi misol oddiy

http://www.w3.org/1998/12/01/chairs

... W3C raislari yig'ilishi bayonnomasi bo'yicha hisobot.

Mavzular va mavzular bo'yicha tasniflash

Men bu xavf haqida batafsil to'xtalib o'taman, chunki bu oldini olish eng qiyin narsalardan biridir. Odatda, hujjatlarni bajargan ishi bo‘yicha toifalarga ajratganingizda mavzular URI-larda tugaydi. Ammo bu buzilish vaqt o'tishi bilan o'zgaradi. Hududlarning nomlari o'zgaradi. W3C da biz bo'limning haqiqiy mazmunini aks ettirish uchun MarkUP ni Markup ga, so'ngra HTML ga o'zgartirmoqchi edik. Bundan tashqari, ko'pincha tekis nomlar maydoni mavjud. 100 yildan keyin hech narsani qayta ishlatishni xohlamasligingizga ishonchingiz komilmi? Qisqa umrimizda biz, masalan, "Tarix" va "Uslublar jadvallari" dan qayta foydalanishni xohladik.

Bu veb-saytni tashkil qilishning jozibali usuli va har qanday narsani, shu jumladan butun Internetni tashkil qilishning chinakam jozibali usuli. Bu ajoyib o'rta muddatli yechim, ammo uzoq muddatda jiddiy kamchiliklarga ega.

Sababning bir qismi ma'no falsafasida yotadi. Tildagi har bir atama klasterlash uchun potentsial maqsaddir va har bir kishi bu nimani anglatishini boshqacha tasavvur qilishi mumkin. Ob'ektlar o'rtasidagi munosabatlar daraxtdan ko'ra ko'proq tarmoqqa o'xshaganligi sababli, hatto tarmoqqa rozi bo'lganlar ham daraxtning boshqa ko'rinishini tanlashlari mumkin. Bular umumiy yechim sifatida ierarxik tasnifning xavf-xatarlari haqidagi (ko'pincha takrorlanadigan) umumiy kuzatishlarim.

Haqiqatan ham, siz URIda mavzu nomidan foydalanganda, siz o'zingizni qandaydir tasnifga bag'ishlaysiz. Ehtimol, kelajakda siz boshqa variantni afzal ko'rasiz. Keyin URI buzilishiga moyil bo'ladi.

Mavzu sohasini URIning bir qismi sifatida ishlatishning sababi shundaki, URI maydonining kichik bo'limlari uchun javobgarlik odatda topshiriladi va keyin sizga ushbu kichik bo'shliq uchun mas'ul bo'lgan tashkiliy organning nomi - bo'lim, guruh yoki boshqa narsa kerak bo'ladi. Bu tashkiliy tuzilma uchun majburiy URI. Agar keyingi (chapdagi) URI sana bilan himoyalangan boʻlsa, bu odatda xavfsiz boʻladi: 1998/rasmlar serveringiz uchun “1998-yilda biz hozir rasm deb ataydigan narsa bilan nima qilgan edik” emas, balki “1998-yilda rasmlar bilan nimani nazarda tutgan edik” degan maʼnoni anglatishi mumkin.

Domen nomini unutmang

Bu nafaqat URI-dagi yo'lga, balki server nomiga ham tegishli ekanligini unutmang. Agar sizda turli xil narsalar uchun alohida serverlar mavjud bo'lsa, esda tutingki, bu bo'linishni ko'plab havolalarni yo'q qilmasdan o'zgartirish mumkin emas. Ba'zi klassik "biz foydalanadigan dasturiy ta'minotga qarang" xatolari "cgi.pathfinder.com", "secure", "lists.w3.org" domen nomlaridir. Ular server boshqaruvini osonlashtirish uchun yaratilgan. Domen kompaniyangizdagi bo'linmani, hujjat holatini, kirish darajasi yoki xavfsizlik darajasini ifodalaydimi, qat'i nazar, bir nechta hujjat turlari uchun bir nechta domen nomidan foydalanishdan oldin juda ehtiyot bo'ling. Qayta yo'naltirish va proksi-serverdan foydalanib, bitta ko'rinadigan veb-server ichida bir nechta veb-serverlarni yashirishingiz mumkinligini unutmang.

Oh, shuningdek, domen nomingiz haqida o'ylang. Mahsulot qatorini o‘zgartirib, sovun ishlab chiqarishni to‘xtatganingizdan so‘ng siz soap.com deb nomlanishini xohlamaysiz (hozirda soap.com egasi kim bo‘lsa, kechirasiz).

xulosa

URI-ni 2, 20, 200 yoki hatto 2000 yil davomida saqlab qolish, ko'rinadigan darajada oson emas. Biroq, butun Internetda veb-ustalar kelajakda bu vazifani o'zlari uchun juda qiyinlashtiradigan qarorlar qabul qilmoqdalar. Ko'pincha bu ularning vazifasi eng yaxshi saytni taqdim etish bo'lgan vositalardan foydalanishi bilan bog'liq - va hech kim hamma narsa o'zgarganda havolalar bilan nima sodir bo'lishini baholamagan. Biroq, bu erda gap shundaki, ko'p, ko'p narsa o'zgarishi mumkin va sizning URIlaringiz bir xil bo'lishi mumkin va qolishi kerak. Bu faqat ularni qanday yaratish haqida o'ylaganingizda mumkin.

Shuningdek qarang .:

Yakob Nilsenning xuddi shu mavzudagi tiradi

Qo'shimchalar

Fayl kengaytmalarini qanday olib tashlash mumkin ...

... joriy faylga asoslangan veb-serverdagi URI-danmi?

Agar siz Apache-dan foydalansangiz, masalan, kontentni muhokama qilish uchun uni sozlashingiz mumkin. Fayl kengaytmasini (masalan, .png) faylga saqlang (masalan, mydog.png), lekin siz usiz veb-resursga ulanishingiz mumkin. Keyin Apache shu nomdagi va istalgan kengaytmali barcha fayllar uchun katalogni tekshiradi va to'plamdan eng yaxshisini tanlashi mumkin (masalan, GIF va PNG). Va har xil turdagi fayllarni turli kataloglarga qo'yishning hojati yo'q, aslida kontentni moslashtirish, agar buni qilsangiz, ishlamaydi.

Kontentni muhokama qilish uchun serveringizni sozlang
Har doim kengaytmasiz URI-larga havola qiling

Kengaytmali havolalar ishlayveradi, lekin serveringiz hozirda va kelajakda mavjud boʻlgan eng yaxshi formatni tanlashiga toʻsqinlik qiladi.

(Aslida, mydog, mydog.png и mydog.gif - amaldagi veb-resurslar, mydog universal kontent turi resursidir va mydog.png и mydog.gif — ma'lum bir kontent turidagi resurslar).

Albatta, agar siz o'z veb-serveringizni yozayotgan bo'lsangiz, doimiy identifikatorlarni joriy shaklga bog'lash uchun ma'lumotlar bazasidan foydalanish yaxshi bo'ladi, lekin ma'lumotlar bazasining cheksiz o'sishidan ehtiyot bo'ling.

Sharmandalik kengashi - 1-hikoya: 7-kanal

1999 yil davomida men sahifada qor tufayli maktab yopilishini kuzatdim http://www.whdh.com/stormforce/closings.shtml. Ma'lumot televizor ekranining pastki qismida paydo bo'lishini kutmang! Bosh sahifamdan unga havola qildim. 2000 yilgi birinchi katta qor bo'roni keladi va men sahifani tekshiraman. U yerda yozilgan:,

- Sifatida.
Hozirda hech narsa yopiq emas. Iltimos, ob-havo haqida ogohlantirilganda qaytib keling.

Bunday kuchli bo'ron bo'lishi mumkin emas. Qizig'i shundaki, sana yo'qolgan. Ammo agar siz saytning asosiy sahifasiga kirsangiz, sahifaga olib boradigan "Yopiq maktablar" katta tugmasi bo'ladi. http://www.whdh.com/stormforce/ yopiq maktablarning uzoq ro'yxati bilan.

Ehtimol, ular ro'yxatni olish uchun tizimni o'zgartirgandirlar - lekin URIni o'zgartirishlari shart emas edi.

Sharmandalik kengashi - 2-hikoya: Microsoft Netmeeting

Internetga qaramlikning kuchayishi bilan ishlab chiqaruvchining veb-saytiga havolalar ilovalarga joylashtirilishi mumkinligi haqida aqlli fikr paydo bo'ldi. Bu juda ko'p ishlatilgan va suiiste'mol qilingan, ammo URL manzilini o'zgartira olmaysiz. Yaqinda men Microsoft Netmeeting 2/bir narsa mijozidan Internet/Bepul narsalar menyusidagi Yordam/Microsoft havolasini sinab ko'rdim va 404 xatosini oldim - serverdan hech qanday javob topilmadi. Ehtimol, u allaqachon tuzatilgan ...

Tarixiy eslatma: 20-asr oxirida, bu yozilganda, "salqin" moda, sifat yoki moslikni ko'rsatadigan, ayniqsa, yoshlar orasida ma'qullash epiteti edi. Shoshilinch ravishda, URI yo'li ko'pincha foydalilik yoki chidamlilik uchun emas, balki "salqinlik" uchun tanlangan. Bu post salqin qidirish ortidagi energiyani qayta yo'naltirishga urinishdir.

Manba: www.habr.com

Salqin URIlar o'zgarmaydi