{"id":89253,"date":"2020-07-21T01:42:24","date_gmt":"2020-07-20T23:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya"},"modified":"2020-07-21T01:42:24","modified_gmt":"2020-07-20T23:42:24","slug":"krutye-uri-ne-izmenyayutsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya","title":{"rendered":"Lahedad URI-d ei muutu","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Autor \u2014 sir Tim Berners-Lee, URI, URL, HTTP, HTML ja World Wide Web'i leiutaja, W3C'i praegune juht. Artikkel on kirjutatud 1998. aastal. <\/p>\n

Millist URI v\u00f5ib pidada \"lahedaks\"?
\nSeda, mis ei muutu.
\nKuidas URI muutuvad?
\nURI ei muutu: need muutuvad inimeste poolt.<\/i> <\/p>\n

Teoreetiliselt ei ole inimestel mingeid p\u00f5hjuseid URI-de muutmiseks (v\u00f5i dokumentide haldamise l\u00f5petamiseks), kuid praktikas on neid miljoneid.<\/p>\n

Teoreetiliselt on domeeninime nominatiivne omanik t\u00f5eliselt domeeninime ruumi omanik ja seega k\u00f5ikide URI-de omanik selles osas. Ainult maksej\u00f5uetuse korral ei takista miski domeeninime omanikul seda nime hoida. Teoreetiliselt on teie domeeninime all olev URI ruum t\u00e4ielikult teie kontrolli all, nii et saate teha selle nii stabiilseks, kui soovite. Suures osas on ainus kaalukas p\u00f5hjus, miks dokument Internetist puudub, see, et domeeninime omanik firma on pankrotis v\u00f5i ei suuda enam serveri t\u00f6\u00f6d toetada. Miks on siis maailmas nii palju kadunud linke? Osaliselt on see lihtsalt etten\u00e4gemise puudumine. Siin on m\u00f5ned p\u00f5hjused, mida v\u00f5ib kuulda:
\n<\/a><\/noindex><\/p>\n

Me lihtsalt reorganiseerisime veebisaidi, et muuta see paremaks.<\/h4>\n

\nKas t\u00f5esti arvate, et vanad URI-d ei saa enam t\u00f6\u00f6tada? Kui jah, siis olete need v\u00e4ga halvasti valinud. M\u00f5elge sellele, et uued p\u00fcsiksid ka j\u00e4rgmisel redigeerimisel.<\/p>\n

Meil on nii palju materjali, et me ei suuda j\u00e4lgida, mis on aegunud, mis on konfidentsiaalne ja mis on endiselt oluline, seet\u00f5ttu arvasime, et oleks parem see k\u00f5ik lihtsalt v\u00e4lja l\u00fclitada.<\/h4>\n

\nV\u00f5in ainult kaasa tunda. W3C on \u00fcle elanud perioodi, mil pidime hoolikalt l\u00e4bi vaatama arhiivimaterjalid, et kontrollida nende konfidentsiaalsust, enne kui need avalikkusele k\u00e4tte anda. Otsus peab olema hoolikalt l\u00e4bi m\u00f5eldud \u2014 veenduge, et igas dokumendis fikseerite sobiva lugejaskonna, loomise kuup\u00e4eva ja ideaaljuhul kehtivuse ajavahemiku. Hoidke neid metaandmeid.<\/p>\n

Kuid me avastasime, et failid tuleb ...<\/h4>\n

\nSee on \u00fcks k\u00f5ige armetumaid vabandusi. Paljud ei tea, et veebiserverid v\u00f5imaldavad teil hallata seoseid objekti URI ja selle tegeliku asukoha vahel failis\u00fcsteemis. Kujutage ette URI ruumi kui abstraktset ruumi, mis on ideaalselt organiseeritud. Seej\u00e4rel kaardistage see igasugusele reaalsusele, mida te tegelikult selle rakendamiseks kasutate. Siis andke sellest veebiserverile teada. Saate isegi kirjutada oma serveri fragmenti, et k\u00f5ik \u00f5igesti teha.<\/p>\n

John ei toeta enam seda faili, n\u00fc\u00fcd teeb seda Jane.<\/p>\n

Kas Johni nimi oli URI-s? Ei, lihtsalt fail oli tema kataloogis? Selge.<\/p>\n

Varem kasutasime selle jaoks CGI-skripti, n\u00fc\u00fcd kasutame binaarprogrammi.<\/h4>\n

\nOn hull idee, et skriptidega loodud lehek\u00fcljed peaksid asuma kaustas \"cgibin\" v\u00f5i \"cgi\". See paljastab, kuidas sa oma veebiserverit k\u00e4itad. Muudates mehhanismi (isegi s\u00e4ilitades sisu), oops \u2014 k\u00f5ik sinu URI-d muutuvad.<\/p>\n

V\u00f5tame n\u00e4iteks Rahvusliku Teadusfondi (NSF):<\/p>\n

NSF veebidokumendid<\/p>\n

http:\/\/www.nsf.gov\/cgi-bin\/pubsys\/browser\/odbrowse.pl<\/pre>\n
\nEsimene leht dokumentide vaatamiseks ei j\u00e4\u00e4 kindlasti p\u00e4rast paar aastat samaks. cgi-bin<\/code>, oldbrowse<\/code> ja pl<\/code>\u00a0\u2014 k\u00f5ik see annab teavet selle kohta, kuidas-me-kuidas-teeme-seda. Kui aga kasutate lehte dokumendi otsimiseks, siis saate esimese tulemuse sama halva:<\/p>\n
Kr\u00fcptoloogia ja kodeerimisteooria t\u00f6\u00f6grupi aruanne<\/p>\n
http:\/\/www.nsf.gov\/cgi-bin\/getpub?nsf9814<\/pre>\n
\ndokumentide indeksileht, kuigi html-dokument ise n\u00e4eb palju parem v\u00e4lja:<\/p>\n
http:\/\/www.nsf.gov\/pubs\/1998\/nsf9814\/nsf9814.htm<\/pre>\n
\nSiin on pealkiri pubs\/1998, mis annab igasugusele tulevasele arhiiviteenusele hea arusaamise 1998. aasta dokumentide klassifikatsiooniskeemidest. Ehkki 2098. aastal v\u00f5ivad dokumentide numbrid v\u00e4lja n\u00e4ha erinevad, ei kujuta ma ette, et see URI ei ole endiselt kehtiv ning see ei h\u00e4iriks NSF-i ega \u00fchtegi muud organisatsiooni, kes arh\u00fc\u00fcvi haldab.<\/p>\n
Ma ei arvanud, et URL-id peavad olema p\u00fcsivad \u2014 ju oli ju URN.<\/h4>\n
\nT\u00f5en\u00e4oliselt on see \u00fcks halvimatest k\u00f5rvalm\u00f5judest URN-i arutelul. Some arvavad, et kuna uurimused p\u00fcsivamate nimetuste ruumide kohta, v\u00f5ivad nad kobamisi suhtuda rippuvatesse linkidesse, kuna 'URN teeb k\u00f5ik korda'. Kui sa oled \u00fcks neist inimestest, siis lase mul sind petta.<\/p>\n
Enamik URN skeeme, mida olen n\u00e4inud, n\u00e4evad v\u00e4lja nagu autoriteedi identifikaator, millele j\u00e4rgneb kas kuup\u00e4ev ja rida, millest te valite, v\u00f5i lihtsalt rida, millest te valite. See on v\u00e4ga sarnane HTTP URI-le. Teisis\u00f5nu, kui arvate, et teie organisatsioon suudab luua pikaealisi URN-e, siis t\u00f5estage seda kohe, kasutades neid oma HTTP URI-de jaoks. HTTP-s endas ei ole midagi, mis teeks teie URI-d ebastabiilseks. Ainult teie organisatsioon. Staatage andmebaas, mis seob dokumendi URN-i praeguse faili nimega, ja laske veebiserveril kasutada seda failide t\u00f5mbamiseks.<\/p>\n
Kui olete siiani j\u00f5udnud, siis kui teil ei ole aega, raha ja kontakte, et arendada mingit tarkvara, v\u00f5ite esitada j\u00e4rgmise vabanduse:<\/p>\n
Me tahtsime, aga meil pole lihtsalt vajalikke t\u00f6\u00f6riistu.<\/h4>\n
\nSeda on t\u00f5eliselt kahetsusv\u00e4\u00e4rne. Ma olen t\u00e4iesti n\u00f5us. K\u00f5ik, mida peate tegema, on sundida veebiserverit viivitamatult t\u00f6\u00f6tlema p\u00fcsivat URI-d ja tagastama faili, kus iganes see teie praeguses kaootilises failis\u00fcsteemis hetkel asub. Soovite salvestada k\u00f5ik URI-d faili kontrollimiseks ja pidevalt hoida andmebaasi ajakohasena. Soovite s\u00e4ilitada suhteid erinevate versioonide ja sama dokumendi t\u00f5lgete vahel ning hoida s\u00f5ltumatut kontrollsummade kirjet, et tagada faili kaitse juhusliku rikke eest. Ning veebiserverid ei tule lihtsalt nende funktsioonidega karbist v\u00e4lja. Kui soovite luua uut dokumenti, palub teie redaktor m\u00e4\u00e4rata URI.<\/p>\n
Teil on vaja v\u00f5imalust muuta omandit, juurdep\u00e4\u00e4su dokumentidele, arhiveerimise taseme turvalisust ja muud URI ruumis ilma URI-d muutmata.<\/p>\n
Asjad on liiga halvad. Kuid me parandame olukorra. W3C-s kasutame me Jigedit funktsionaalsust (Jigsaw server dokumendi redigeerimiseks), mis j\u00e4lgib versioone, ja katsetame dokumentide loomise skripte. Kui arendate t\u00f6\u00f6riistu, servereid ja kliente, v\u00f5tke seda teemat t\u00f5siselt!<\/p>\n
See vabandus kehtib ka paljudele W3C lehtedele, sealhulgas sellele: tehke seda, mida ma \u00fctlen, mitte seda, mida ma teen.<\/p>\n
Miks peaks see mind huvitama?<\/h1>\n
\nKui muudate URI oma serveris, ei saa te kunagi t\u00e4ielikult teada, kellel on lingid vana URI-le. Need v\u00f5ivad olla lingid tavaliselt veebilehtedelt. Raamatupidamised teie lehele. URI v\u00f5is olla kirjutatud s\u00f5bra kiri servale.<\/p>\n
Kui keegi klikib lingile ja see on katki, kaotab ta tavaliselt usalduse serveri omaniku vastu. Ta tunneb samuti pettumust \u2014 nii emotsionaalselt kui ka reaalselt, kui ei suuda oma eesm\u00e4rki saavutada.<\/p>\n
Paljud inimesed kaebavad pidevalt katki linkide \u00fcle ja ma loodan, et kahju on ilmne. Loodan, et ka mainekahju serveri hooldajatusele, kust dokument kadunud on, on samuti ilmne.<\/p>\n
Nii et mida ma peaksin tegema? URI kujundus<\/h1>\n
\nSee on veebi arendaja kohustus \u2014 v\u00e4lja tuua URI-d, mida saab kasutada kahe aasta, kahek\u00fcmne aasta v\u00f5i kahek\u00fcmne aasta p\u00e4rast. Selleks on vajalik l\u00e4bim\u00f5eldus, organiseeritus ja sihikindlus.<\/p>\n
URI-d muutuvad, kui neis sisalduv teave muutub. On v\u00e4ga oluline, kuidas te neid projekteerite. (Mida, URI disain? Kas ma pean URI-d projekteerima? Jah, te peaksite sellele m\u00f5tlema). Projekteerimine t\u00e4hendab peamiselt seda, et URI-s ei ole mingit teavet.<\/p>\n
Dokumendi loomise kuup\u00e4ev \u2014 URI v\u00e4ljastamise kuup\u00e4ev \u2014 on asjaolu, mis ei muutu kunagi. See on v\u00e4ga kasulik, et eristada p\u00e4ringuid, mis kasutavad uut s\u00fcsteemi, neist, mis kasutavad vana s\u00fcsteemi. Sellel on hea alustada URI-d. Kui dokumendil on m\u00f5ni kuup\u00e4ev m\u00e4rgitud, isegi kui dokument on tulevikus asjakohane, on see hea algus.<\/p>\n
Ainus erand on leht, mis on meelega \u00abviimane\u00bb versioon, n\u00e4iteks kogu organisatsiooni v\u00f5i suure osa jaoks.<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/latest\/<\/pre>\n
\nSee on viimane Money Daily veerg Money ajakirjas. Peamine p\u00f5hjus, miks selles URI-s pole kuup\u00e4eva, on see, et pole mingit p\u00f5hjust s\u00e4ilitada URI-d, mis kestab kauem kui ajakiri. Konseptsioon Money Daily kaob koos Money-ga. Kui soovite sisu k\u00e4sitleda, tuleks seda eraldi viidata arhiivides:<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/1998\/981212.moneyonline.html<\/pre>\n
\n(N\u00e4eb hea v\u00e4lja. Eeldab, et \"money\" t\u00e4hendab pathfinder.com-i jooksul sama asja. On dubleerimist \"98\" ja tarbetu \".html\", kuid muidu tundub see tugev URI.<\/p>\n
Mida k\u00f5rvale j\u00e4tta<\/h4>\n
\nK\u00f5ik! Lisaks loomiskuup\u00e4evale, kui panete mingit teavet URI-sse, otsite te nii v\u00f5i naa probleme.<\/p>\n