{"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 ei muutu","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Autor \u2014 sir Tim Berners-Lee, URI, URL, HTTP, HTML ja WWW leiutaja, W3C tegevjuht. Artikkel on kirjutatud 1998. aastal <\/p>\n

Millist URI v\u00f5ib pidada \"lahedaks\"?
\nSellist, mis ei muutu.
\nKuidas URI-d muutuvad?
\nURI-d ei muutu: neid muudavad inimesed.<\/i> <\/p>\n

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

Teoreetiliselt omab nimeline domeeniruumi omanik t\u00f5eliselt domeeniruumi ja seega k\u00f5iki URI-sid selles. V\u00e4lja arvatud maksej\u00f5uetuse korral ei takista miski domeeni omaniku nime hoidmist. Ja teoreetiliselt on teie domeeninime all olev URI ruum t\u00e4ielikult teie kontrolli all, nii et saate seda muuta nii stabiilseks, kui soovite. Peamine p\u00f5hjus dokumendi kadumiseks internetist on, et domeeni omav ettev\u00f5te on l\u00f5petanud tegevuse v\u00f5i ei suuda enam serverit toetada. Miks on maailmas nii palju kadunud linke? Osaliselt on see lihtsalt ettevaatamatuse puudumine. Siin on m\u00f5ned p\u00f5hjused, mida v\u00f5ib kuulda:
\n<\/a><\/noindex><\/p>\n

Me lihtsalt reorganiseerisime veebilehte, et teha see paremaks.<\/h4>\n

\nKas t\u00f5esti arvate, et vanad URI-d ei saa enam t\u00f6\u00f6tada? Kui jah, siis valisite need v\u00e4ga halvasti. M\u00f5elge, kuidas need saaksid p\u00e4rast j\u00e4rgmist uuendamist s\u00e4ilida.<\/p>\n

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

\nV\u00f5in vaid kaastundlikult n\u00f5ustuda. W3C on kogenud perioodi, mil pidime hoolikalt l\u00e4bivalima arhiivimaterjale privaatsete andmete osas, enne kui need avalikuks teha. Otsused tuleb teha ettevaatlikult \u2013 veenduge, et salvestate iga dokumendi soovitud lugejate ringi, loomise kuup\u00e4eva ja ideaaljuhul ka kehtivuse t\u00e4htaega. S\u00e4ilitage need metaandmed.<\/p>\n

Nii, me avastasime, et faile tuleb liikuda\u2026<\/h4>\n

\nSee on \u00fcks k\u00f5ige haledamaid \u00f5igustusi. Paljud ei tea, et veebiserverid v\u00f5imaldavad juhtida seost URI objekti ja selle tegeliku asukoha vahel failis\u00fcsteemis. Kujutage ette URI ruumi kui abstraktset ruumi, mis on ideaalselt korraldatud. Seej\u00e4rel tehke kaardistus igasugusele reaalsusele, mida te tegelikult selle rakendamiseks kasutate. Siis teavitage sellest veebiserverit. Te v\u00f5ite isegi kirjutada oma serveri fragmenti, et k\u00f5ik \u00f5igesti toimida.<\/p>\n

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

Kas Johns nimi oli URI-s? Ei, lihtsalt fail asus tema kataloogis? No selge.<\/p>\n

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

\nOn hull idee, et skriptide poolt loodud lehed peavad olema paigutatud \"cgibin\" v\u00f5i \"cgi\" alasse. See paljastab, kuidas k\u00e4itate oma veebiserverit. Muutke mehhanismi (isegi kui sisu j\u00e4\u00e4b samaks) ja ups \u2013 k\u00f5ik teie URI-d muutuvad.<\/p>\n

V\u00f5tame n\u00e4iteks Ameerika \u00dchendriikide Rahvuslik Teadusfond (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 ilmselt selliseks m\u00f5ne aasta p\u00e4rast. cgi-bin<\/code>, oldbrowse<\/code> ja pl<\/code>\u00a0\u2014 k\u00f5ik see annab teavet, kuidas-me-seda-teeme-kuidagi. Kui te aga kasutate lehte dokumendi leidmiseks, saate esimesena sama halva tulemuse:<\/p>\n
Kr\u00fcptograafia ja kooditeooria t\u00f6\u00f6r\u00fchma aruanne<\/p>\n
http:\/\/www.nsf.gov\/cgi-bin\/getpub?nsf9814<\/pre>\n
\ndokumendi indeksilehe jaoks, kuigi HTML-dokument ise n\u00e4eb palju parem v\u00e4lja:<\/p>\n
http:\/\/www.nsf.gov\/pubs\/1998\/nsf9814\/nsf9814.htm<\/pre>\n
\nSiin pealkiri pubs\/1998 annab igale tulevikule arhiveerimisteenusele hea v\u00f5tme, et m\u00f5ista, kuidas toimib vana dokumendi klassifitseerimiskeem 1998. aastast. Kuigi 2098. aastal v\u00f5ivad dokumendi numbrid v\u00e4lja n\u00e4ha teisiti, usun, et see URI on endiselt kehtiv ning see ei takista NSF-i ega \u00fchtegi muud organisatsiooni, kes archiivi haldavad.<\/p>\n
Ma ei arvanud, et URL-id peaksid olema p\u00fcsivad \u2013 olid ju olemas URN-id.<\/h4>\n
\nSee on t\u00f5en\u00e4oliselt \u00fcks halvim k\u00f5rvalm\u00f5ju URN-ide arutelu puhul. M\u00f5ned arvavad, et kuna uuritakse p\u00fcsivama nimeruumi teemadel, v\u00f5ivad nad liikvel linkide osas hooletud olla, kuna \"URN lahendab selle k\u00f5ik\". Kui olete \u00fcks neist inimestest, siis lubage mul teid pettumust valmistada.<\/p>\n
Enamik n\u00e4iteid URN scheemidest, mida olen n\u00e4inud, n\u00e4evad v\u00e4lja nagu autoriteedi identifikaator, millele j\u00e4rgneb kas kuup\u00e4ev ja valitud string v\u00f5i lihtsalt valitud string. See sarnaneb v\u00e4ga HTTP URI-le. Teisis\u00f5nu, kui arvate, et teie organisatsioon suudab luua pikaajalisi URN-e, siis t\u00f5estage seda kohe, kasutades neid oma HTTP URI-de jaoks. HTTP-s endas ei ole midagi, mis teeks teie URI ebastabiilseks. Ainult teie organisatsioon. Looge andmebaas, mis seob dokumendi URN-i praeguse faili nimega, ja laske veebiserveril seda kasutada failide t\u00f5mbamiseks.<\/p>\n
Kui olete siiani j\u00f5udnud, siis kui teil pole aega, raha ja kontakte, et arendada mingit tarkvara, v\u00f5ite esitada j\u00e4rgmise \u00f5igustuse:<\/p>\n
Me tahtsime, aga meil pole lihtsalt vajalikke t\u00f6\u00f6riistu.<\/h4>\n
\nSellele saab t\u00f5eliselt kaasa tunda. Olen t\u00e4ielikult n\u00f5us. Mida peate tegema, on sundida veebiserverit koheselt t\u00f6\u00f6tlema p\u00fcsivat URI-d ja tooma faili, olenemata sellest, kus see hetkel teie praeguses hullumeelses failis\u00fcsteemis asub. Soovite hoida k\u00f5iki URI-sid failis kontrollimiseks ja pidevalt p\u00e4eva peal olevat andmebaasi. Soovite s\u00e4ilitada seoseid erinevate versioonide ja t\u00f5lgete vahel \u00fche ja sama dokumendi vahel, samuti s\u00e4ilitada s\u00f5ltumatu kontrollsummade salvestus, et kaitsta faili kahjustumise eest juhuslike vigade t\u00f5ttu. Ja veebiserverid ei ole lihtsalt valmis nende funktsioonidega. Kui soovite luua uue dokumendi, palub teie toimetaja m\u00e4\u00e4rata URI.<\/p>\n
Teil on vaja v\u00f5imalust muuta omandit, dokumentidele juurdep\u00e4\u00e4su, arhiivi turvatasemete taset jms URI ruumis ilma URI-d muutmata.<\/p>\n
K\u00f5ik on liiga halb. Aga me parandame selle. W3C-s kasutame me Jigedit funktsionaalsust (Jigsaw server redigeerimise jaoks), mis j\u00e4lgib versioone, ja katsetame dokumentide loomise skripte. Kui arendate t\u00f6\u00f6riistu, servereid ja kliente, p\u00f6\u00f6rake sellele probleemile t\u00e4helepanu!<\/p>\n
See \u00f5igustus kehtib ka paljude W3C lehtede kohta, sealhulgas selle kohta: nii et tehke seda, mida ma \u00fctlen, mitte seda, mida ma teen.<\/p>\n
Miks peaks see mind huvitama?<\/h1>\n
\nKui muudad URI oma serveris, ei saa sa kunagi t\u00e4ielikult \u00f6elda, kellel on lingid vana URI peale. Need v\u00f5ivad olla lingid tavalistelt veebilehtedelt. Suhtlemisvihikud sinu lehe kohta. URI v\u00f5idi olla kirjutatud s\u00f5bra kirjale servale.<\/p>\n
Kui keegi klikib lingil ja see on katki, siis kaotab ta tavaliselt usalduse serveri omaniku vastu. Ta on samuti pettunud - nii emotsionaalselt kui ka reaalselt, kuna ei saa saavutada oma eesm\u00e4rki.<\/p>\n
Paljud inimesed kaebavad pidevalt rikutud linkide \u00fcle ja loodan, et kahju on ilmne. Loodan, et samuti on ilmne mainekahju serveri haldajale, kus dokument kadus.<\/p>\n
Mis ma peaksin tegema? URI kavandamine.<\/h1>\n
\nSee on veebimeistri kohustus v\u00e4lja valida URI-d, mida saab kasutada kahe aasta, kahek\u00fcmne aasta v\u00f5i kaheaasta jooksul. Selleks on vajalikud hoolivus, organiseeritus ja sihikindlus.<\/p>\n
URI-d muutuvad, kui neis muutub mingi teave. On v\u00e4ga oluline, kuidas sa neid kavandad. (Mida, URI kavandamine? Ma pean kavandama URI-d? Jah, sa pead sellele m\u00f5tlema). Kavandamine t\u00e4hendab peamiselt selle puudumist URI-s.<\/p>\n
Dokumendi loomise kuup\u00e4ev - URI v\u00e4ljastamise kuup\u00e4ev - on see, mis ei muutu kunagi. See on v\u00e4ga kasulik erinevate p\u00e4ringute eristamiseks, mis kasutavad uut s\u00fcsteemi, vanast s\u00fcsteemist. Sellega on hea alustada URI-d. Kui dokumendil on mingi kuup\u00e4ev, isegi kui dokument j\u00e4\u00e4b tulevikus asjakohaseks, on see hea algus.<\/p>\n
Ainus erand on leht, mis on teadlikult 'l\u00f5plik' versioon, n\u00e4iteks kogu organisatsiooni v\u00f5i suure osa jaoks.<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/latest\/<\/pre>\n
\nSee on Money Daily viimane veerg ajakirjas Money. Peamine p\u00f5hjus, miks selles URI-s ei ole vajalik kuup\u00e4ev, on see, et ei ole mingeid p\u00f5hjuseid s\u00e4ilitada URI-d, mis \u00fcletab ajakirja. Rahanduse m\u00f5isted kaovad koos rahaga. Kui soovite viidata sisule, peaksite viitama sellele eraldi arhiivides:<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/1998\/981212.moneyonline.html<\/pre>\n
\n(N\u00e4eb hea v\u00e4lja. Oletab, et \"money\" t\u00e4hendavad kogu aega pathfinder.com-i eksisteerimise jooksul sama. On korduv \"98\" ja tarbetu \".html\", aga muidu n\u00e4eb see v\u00e4lja nagu tugev URI.<\/p>\n
Mida k\u00f5rvale j\u00e4tta.<\/h4>\n
\nK\u00f5ik! Lisaks loomiskuup\u00e4evale, kui paned mistahes teabe URI-sse, kutsub see paratamatult esile probleeme.<\/p>\n