Autorius: seras Timas Bernersas-Lee, URI, URL, HTTP, HTML ir pasaulinio žiniatinklio išradėjas ir dabartinis W3C vadovas. Straipsnis parašytas 1998 m

Koks URI laikomas „kietu“?
Toks, kuris nesikeičia.
Kaip keičiami URI?
URI nesikeičia: žmonės juos keičia.

Teoriškai žmonėms nėra jokios priežasties keisti URI (arba nustoti teikti patvirtinamuosius dokumentus), tačiau praktiškai jų yra milijonai.

Teoriškai nominalus domeno vardų erdvės savininkas iš tikrųjų priklauso domeno vardų erdvei, taigi ir visiems joje esantiems URI. Išskyrus nemokumą, niekas netrukdo domeno vardo savininkui pasilikti vardą. Ir teoriškai URI erdvę po jūsų domeno pavadinimu visiškai valdote jūs, todėl galite padaryti ją tokią stabilią, kiek norite. Beveik vienintelė gera priežastis, kodėl dokumentas dingsta iš interneto, yra ta, kad įmonė, kuriai priklausė domeno vardas, nustojo veikti arba nebegali sau leisti palaikyti serverio. Tada kodėl pasaulyje tiek trūksta grandžių? Dalis to yra tiesiog neapgalvotumas. Štai keletas priežasčių, kurias galite išgirsti:

Mes ką tik pertvarkėme svetainę, kad ją pagerintume.

Ar tikrai manote, kad seni URI nebegali veikti? Jei taip, vadinasi, juos pasirinkote labai prastai. Apsvarstykite galimybę pasilikti naujus kitam perdarymui.

Turime tiek daug dalykų, kad negalime sekti, kas pasenusi, kas konfidencialu ir kas vis dar aktualu, todėl nusprendėme, kad geriausia visa tai išjungti.

Galiu tik užjausti. W3C išgyveno laikotarpį, kai prieš paskelbdami viešai turėjome atidžiai išnagrinėti archyvinę medžiagą, kad jos būtų konfidencialios. Sprendimas turėtų būti apgalvotas iš anksto – pasirūpinkite, kad prie kiekvieno dokumento būtų įrašyta priimtina skaitytojų auditorija, sukūrimo data ir, idealiu atveju, galiojimo laikas. Išsaugokite šiuos metaduomenis.

Na, mes atradome, kad turime perkelti failus...

Tai vienas apgailėtiniausių pasiteisinimų. Daugelis žmonių nežino, kad žiniatinklio serveriai leidžia valdyti ryšį tarp objekto URI ir jo faktinės vietos failų sistemoje. Pagalvokite apie URI erdvę kaip apie abstrakčią erdvę, puikiai sutvarkytą. Tada sukurkite bet kokią realybę, kurią iš tikrųjų naudojate, kad ją suvoktumėte. Tada praneškite apie tai žiniatinklio serveriui. Jūs netgi galite parašyti savo serverio fragmentą, kad jis būtų teisingas.

Džonas šio failo nebetvarko, o Džeinė dabar tai daro.

Ar Jono vardas buvo URI? Ne, ar failas buvo tik jo kataloge? Na, gerai.

Anksčiau tam naudojome CGI scenarijų, o dabar naudojame dvejetainę programą.

Kyla beprotiška idėja, kad puslapiai, sukurti pagal scenarijus, turėtų būti „cgibin“ arba „cgi“ srityje. Tai atskleidžia žiniatinklio serverio valdymo mechaniką. Keičiate mechanizmą (netgi išsaugodami turinį), o oi – pasikeičia visi jūsų URI.

Pavyzdžiui, Nacionalinis mokslo fondas (NSF):

NSF internetiniai dokumentai

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

Pirmas puslapis, kuriame bus pradėta žiūrėti dokumentus, akivaizdu, kad po kelerių metų neliks toks pat. cgi-bin, oldbrowse и pl - visa tai suteikia informacijos apie tai, kaip mes darome tai dabar. Jei naudojate puslapį dokumento paieškai, pirmasis gautas rezultatas bus toks pat blogas:

Kriptologijos ir kodavimo teorijos darbo grupės ataskaita

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

dokumento rodyklės puslapiui, nors pats html dokumentas atrodo daug geriau:

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

Čia pubs/1998 antraštė suteiks bet kuriai būsimai archyvų tarnybai gerą supratimą, kad galioja senoji 1998 m. dokumentų klasifikavimo schema. Nors 2098 m. dokumentų numeriai gali atrodyti kitaip, aš įsivaizduočiau, kad šis URI vis tiek galiotų ir netrukdytų NSF ar kitai organizacijai, kuri prižiūrėtų archyvą.

Nemaniau, kad URL turi būti nuolatiniai – buvo URN.

Tai tikriausiai yra vienas iš blogiausių URN diskusijų šalutinių poveikių. Kai kurie žmonės mano, kad dėl nuolatinės vardų erdvės tyrimų jie gali būti nerūpestingi kabančių nuorodų atžvilgiu, nes „URN viską išspręs“. Jei esate vienas iš šių žmonių, leiskite man jus nuvilti.

Dauguma mano matytų URN schemų atrodo kaip autoriteto identifikatorius, po kurio nurodoma data ir jūsų pasirinkta eilutė arba tik jūsų pasirinkta eilutė. Tai labai panašu į HTTP URI. Kitaip tariant, jei manote, kad jūsų organizacija galės sukurti ilgalaikius URN, įrodykite tai dabar naudodami juos savo HTTP URI. Pačiame HTTP nėra nieko, dėl ko jūsų URI būtų nestabilus. Tik jūsų organizacija. Sukurkite duomenų bazę, susiejančią dokumento URN su dabartiniu failo pavadinimu, ir leiskite žiniatinklio serveriui jį naudoti, kad iš tikrųjų nuskaitytų failus.

Jei pasiekėte šį tašką, jei neturite laiko, pinigų ir ryšių programinei įrangai kurti, galite pateikti tokį pasiteisinimą:

Norėjome, bet tiesiog neturime tinkamų įrankių.

Bet jūs galite tai užjausti. Aš visiškai sutinku. Ką reikia padaryti, tai priversti žiniatinklio serverį akimirksniu išanalizuoti nuolatinį URI ir grąžinti failą ten, kur jis šiuo metu saugomas jūsų dabartinėje beprotiškoje failų sistemoje. Norite saugoti visus URI faile kaip čekį ir nuolat atnaujinti duomenų bazę. Norite išsaugoti ryšį tarp skirtingų to paties dokumento versijų ir vertimų, taip pat išlaikyti nepriklausomą kontrolinės sumos įrašą, kad įsitikintumėte, jog failas nėra sugadintas dėl atsitiktinės klaidos. Be to, žiniatinklio serveriai tiesiog neišnyksta su šiomis funkcijomis. Kai norite sukurti naują dokumentą, redaktorius paprašys nurodyti URI.

URI erdvėje turite turėti galimybę pakeisti nuosavybės teisę, prieigą prie dokumentų, archyvo lygio apsaugą ir pan., nekeičiant URI.

Viskas labai blogai. Bet mes ištaisysime situaciją. W3C mes naudojame Jigedit (Jigsaw redagavimo serverio) funkciją, kuri seka versijas, ir eksperimentuojame su dokumentų generavimo scenarijais. Jei kuriate įrankius, serverius ir klientus, atkreipkite dėmesį į šią problemą!

Šis pasiteisinimas taip pat tinka daugeliui W3C puslapių, įskaitant šį: taigi daryk taip, kaip sakau, o ne taip, kaip darau.

Kodėl man turėtų rūpėti?

Kai pakeičiate URI savo serveryje, niekada negalite iki galo pasakyti, kas turės nuorodas į senąjį URI. Tai gali būti nuorodos iš įprastų tinklalapių. Pažymėkite savo puslapį. URI galėjo būti nubraižytas laiško draugui paraštėse.

Kai kas nors seka nuorodą ir ji sugenda, jie paprastai praranda pasitikėjimą serverio savininku. Jis taip pat yra nusivylęs tiek emociškai, tiek fiziškai, nes negali pasiekti savo tikslo.

Daugelis žmonių nuolat skundžiasi dėl neveikiančių nuorodų, ir tikiuosi, kad žala yra akivaizdi. Tikiuosi, kad akivaizdi ir serverio, kuriame dingo dokumentas, prižiūrėtojo reputacija.

Taigi ką turėčiau daryti? URI dizainas

Žiniatinklio valdytojas yra atsakingas už URI, kurie gali būti naudojami per 2 metus, po 20 metų, per 200 metų, paskirstymą. Tam reikia apgalvoto, organizuotumo ir ryžto.

URI keičiasi, jei pasikeičia bet kokia juose esanti informacija. Labai svarbu, kaip juos suprojektuosite. (Kas, URI dizainas? Ar man reikia sukurti URI? Taip, turėtumėte apie tai pagalvoti). Dizainas iš esmės reiškia bet kokios informacijos nepateikimą URI.

Dokumento sukūrimo data – URI išdavimo data – niekada nepasikeis. Tai labai naudinga norint atskirti užklausas, kuriose naudojama nauja sistema, nuo tų, kurios naudoja seną sistemą. Tai gera vieta pradėti nuo URI. Jei dokumentas turi datą, net jei dokumentas bus aktualus ateityje, tai yra gera pradžia.

Vienintelė išimtis yra puslapis, kuris sąmoningai yra „naujausia“ versija, pavyzdžiui, visai organizacijai ar didelei jos daliai.

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

Tai naujausia „Money Daily“ rubrika žurnale „Money“. Pagrindinė priežastis, dėl kurios šiame URI nereikia datos, yra ta, kad nėra jokios priežasties saugoti URI, kuris galioja ilgiau nei žurnalas. Money Daily sąvoka išnyks, kai išnyks pinigai. Jei norite susieti turinį, turėtumėte jį atskirai pateikti archyvuose:

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

(Atrodo gerai. Daroma prielaida, kad „pinigai“ visą pathfinder.com gyvenimą reikš tą patį. Yra „98“ dublikatas ir nereikalingas „.html“, bet kitu atveju atrodo kaip stiprus URI.

Ką palikti nuošalyje

Viskas! Be sukūrimo datos, bet kokios informacijos įtraukimas į URI vienaip ar kitaip sukelia problemų.

• Autoriaus vardas. Autorystė gali pasikeisti, kai pasirodys naujos versijos. Žmonės palieka organizacijas ir perduoda daiktus kitiems.
• Tema. Tai yra labai sunku. Iš pradžių visada atrodo gerai, bet stebėtinai greitai keičiasi. Daugiau apie tai pakalbėsiu žemiau.
• Padėtis. Katalogai, tokie kaip „senas“, „juodraštis“ ir t. t., jau nekalbant apie „naujiausias“ ir „kietas“, yra visose failų sistemose. Dokumentai keičia būseną – kitaip nebūtų prasmės kurti juodraščius. Naujausiai dokumento versijai reikalingas nuolatinis identifikatorius, neatsižvelgiant į jo būseną. Saugokite statusą pavadinime.
• Prieiga. W3C svetainę suskirstėme į skyrius, skirtas darbuotojams, nariams ir visuomenei. Tai skamba gerai, bet, žinoma, dokumentai prasideda kaip komandos idėjos, aptariamos su nariais, o tada tampa viešai žinomi. Tikrai būtų gaila, jei kiekvieną kartą atveriant dokumentą platesnei diskusijai, visos senos nuorodos į jį nutrūktų! Dabar pereiname prie paprasto datos kodo.
• Failo plėtinys. Labai dažnas reiškinys. „cgi“, net „.html“ ateityje pasikeis. Galbūt šiame puslapyje nenaudosite HTML 20 metų, tačiau šiandieninės nuorodos į jį vis tiek turėtų veikti. Kanoninės nuorodos W3C svetainėje nenaudoja plėtinio (kaip tai daroma).
• Programinės įrangos mechanizmai. URI ieškokite „cgi“, „exec“ ir kitų terminų, kurie šaukia „pažiūrėkite, kokią programinę įrangą naudojame“. Ar kas nors nori praleisti visą savo gyvenimą rašydamas Perl CGI scenarijus? Ne? Tada pašalinkite plėtinį .pl. Perskaitykite serverio vadovą, kaip tai padaryti.
• Disko pavadinimas. Nagi! Bet aš tai mačiau.

Taigi geriausias pavyzdys iš mūsų svetainės yra tiesiog

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

... ataskaita apie W3C pirmininkų susirinkimo protokolą.

Temos ir klasifikacija pagal temas

Pakalbėsiu apie šį pavojų išsamiau, nes tai vienas iš tų dalykų, kurių sunkiausia išvengti. Paprastai temos patenka į URI, kai suskirstote dokumentus į kategorijas pagal jų atliekamą darbą. Tačiau šis suskirstymas laikui bėgant pasikeis. Teritorijų pavadinimai keisis. W3C norėjome pakeisti MarkUP į Markup, o tada į HTML, kad atspindėtų tikrąjį skyriaus turinį. Be to, dažnai yra plokščia vardų erdvė. Ar po 100 metų tikrai nenorėsite nieko pakartotinai naudoti? Per savo trumpą gyvenimą jau norėjome pakartotinai panaudoti, pavyzdžiui, „Istoriją“ ir „Stiliaus lapus“.

Tai viliojantis būdas tvarkyti svetainę ir tikrai viliojantis būdas tvarkyti bet ką, įskaitant visą žiniatinklį. Tai puikus vidutinės trukmės sprendimas, tačiau ilgalaikėje perspektyvoje jis turi rimtų trūkumų.

Dalis priežasties slypi prasmės filosofijoje. Kiekvienas kalbos terminas yra potencialus grupavimo tikslas, ir kiekvienas žmogus gali skirtingai suprasti, ką jis reiškia. Kadangi santykiai tarp objektų yra labiau panašūs į tinklą, o ne į medį, net tie, kurie sutinka su žiniatinkliu, gali pasirinkti kitokį medžio atvaizdavimą. Tai mano (dažnai kartojami) bendri pastebėjimai apie hierarchinės klasifikacijos, kaip bendro sprendimo, pavojus.

Tiesą sakant, kai URI naudojate temos pavadinimą, įsipareigojate tam tikram klasifikavimui. Galbūt ateityje pasirinksite kitą variantą. Tada URI bus pažeistas.

Priežastis, kodėl dalykinė sritis naudojama kaip URI dalis, yra ta, kad atsakomybė už URI erdvės poskyrius paprastai perduodama, o tada jums reikia organizacinio organo – departamento, grupės ar bet kokio – pavadinimo, kuris yra atsakingas už tą poerdvę. Tai URI, susietas su organizacine struktūra. Paprastai tai saugu tik tada, jei tolesnis (kairysis) URI yra apsaugotas data: 1998/pics jūsų serveriui gali reikšti „ką turėjome omenyje 1998 m. su nuotraukomis“, o ne „ką 1998 m. padarėme su tuo, ką dabar vadiname nuotraukomis“.

Nepamirškite domeno vardo

Atminkite, kad tai taikoma ne tik keliui URI, bet ir serverio pavadinimui. Jei turite atskirus serverius skirtingiems dalykams, atminkite, kad šio skirstymo bus neįmanoma pakeisti nesugriaunant daugybės nuorodų. Kai kurios klasikinės „pažiūrėkite į šiandien naudojamą programinę įrangą“ klaidos yra domenų pavadinimai „cgi.pathfinder.com“, „secure“, „lists.w3.org“. Jie skirti palengvinti serverio administravimą. Nepriklausomai nuo to, ar domenas yra jūsų įmonės padalinys, dokumento būsena, prieigos lygis ar saugos lygis, būkite labai labai atsargūs prieš naudodami daugiau nei vieną domeno pavadinimą keliems dokumentų tipams. Atminkite, kad galite paslėpti kelis žiniatinklio serverius viename matomame žiniatinklio serveryje naudodami peradresavimą ir tarpinį serverį.

Taip pat pagalvokite apie savo domeno vardą. Pakeitę produktų linijas ir nustoję gaminti muilą, nenorite būti vadinami soap.com (atsiprašau tų, kuriems šiuo metu priklauso soap.com).

išvada

Akivaizdu, kad išsaugoti URI 2, 20, 200 ar net 2000 metų nėra taip paprasta, kaip atrodo. Tačiau visame internete žiniatinklio valdytojai priima sprendimus, dėl kurių ateityje ši užduotis jiems tikrai bus sunki. Dažnai taip yra todėl, kad jie naudoja įrankius, kurių užduotis yra pateikti tik šiuo metu geriausią svetainę – ir niekas neįvertino, kas bus su nuorodomis, kai viskas pasikeis. Tačiau esmė ta, kad daug, daug dalykų gali pasikeisti, o jūsų URI gali ir turėtų likti tokie patys. Tai įmanoma tik tada, kai galvojate apie tai, kaip juos kuriate.

Taip pat žiūrėkite:

• Jakobo Nielseno tirada ta pačia tema

Papildymai

Kaip pašalinti failų plėtinius...

...iš URI dabartiniame failų pagrindu veikiančiame žiniatinklio serveryje?

Pavyzdžiui, jei naudojate „Apache“, galite sukonfigūruoti ją derėtis dėl turinio. Išsaugokite failo plėtinį (pvz., .png) faile (pvz., mydog.png), bet galite susieti su žiniatinklio šaltiniu ir be jo. Tada „Apache“ patikrina, ar kataloge nėra visų failų tokiu pavadinimu ir bet kokiu plėtiniu, ir gali pasirinkti geriausią iš rinkinio (pvz., GIF ir PNG). Ir nereikia dėti skirtingų tipų failų į skirtingus katalogus, iš tikrųjų turinio atitikimas neveiks, jei tai padarysite.

• Nustatykite serverį, kad galėtumėte derėtis dėl turinio
• Visada susiekite su URI be plėtinio

Nuorodos su plėtiniais vis tiek veiks, tačiau serveris negalės pasirinkti geriausio šiuo metu ir ateityje galimo formato.

(Faktiškai, mydog, mydog.png и mydog.gif — galiojančius žiniatinklio išteklius, mydog yra universalus turinio tipo šaltinis ir mydog.png и mydog.gif — konkretaus turinio tipo ištekliai).

Žinoma, jei rašote savo žiniatinklio serverį, verta naudoti duomenų bazę, kad susieti nuolatinius identifikatorius su dabartine forma, nors saugokitės neriboto duomenų bazės augimo.

Gėdos lenta – 1 istorija: 7 kanalas

1999 m. puslapyje stebėjau mokyklų uždarymus dėl sniego http://www.whdh.com/stormforce/closings.shtml. Nelaukite, kol informacija pasirodys televizoriaus ekrano apačioje! Pateikiau nuorodą į jį iš savo pagrindinio puslapio. Atkeliauja pirmoji didelė 2000 sniego audra ir aš patikrinu puslapį. Ten parašyta:,

- Nuo.
Šiuo metu niekas nėra uždarytas. Įspėjus apie orą, prašome grįžti.

Negali būti tokia stipri audra. Juokinga, kad trūksta datos. Bet jei pateksite į pagrindinį svetainės puslapį, ten bus didelis mygtukas „Uždarytos mokyklos“, kuris nukreipia į puslapį http://www.whdh.com/stormforce/ su ilgu uždarytų mokyklų sąrašu.

Galbūt jie pakeitė sąrašo gavimo sistemą, bet jiems nereikėjo keisti URI.

Gėdos lenta – 2 istorija: „Microsoft Netmeeting“.

Didėjant priklausomybei nuo interneto, kilo gudri idėja, kad nuorodos į gamintojo svetainę galėtų būti įterptos į programas. Tai buvo dažnai naudojama ir piktnaudžiaujama, bet negalite pakeisti URL. Kaip tik kitą dieną bandžiau nuorodą iš „Microsoft Netmeeting 2/something“ kliento, esančio meniu „Help/Microsoft on the Web/Free stuff“, ir gavau 404 klaidą – atsakymo iš serverio nerasta. Gal jau sutvarkyta...

© 1998 Timas BL

Istorinė pastaba: XX amžiaus pabaigoje, kai tai buvo parašyta, „kietas“ buvo pritarimo epitetas, ypač tarp jaunų žmonių, nurodantis madingumą, kokybę ar tinkamumą. Paskubėjus, URI kelias dažnai buvo pasirinktas dėl „vėsumo“, o ne dėl naudingumo ar ilgaamžiškumo. Šis įrašas yra bandymas nukreipti energiją, esančią už šaunumo paieškų.

Šaltinis: www.habr.com