Autor — sir Tim Berners-Lee, URI, URL, HTTP, HTML ja World Wide Web'i leiutaja, W3C'i praegune juht. Artikkel on kirjutatud 1998. aastal.

Millist URI võib pidada "lahedaks"?
Seda, mis ei muutu.
Kuidas URI muutuvad?
URI ei muutu: need muutuvad inimeste poolt.

Teoreetiliselt ei ole inimestel mingeid põhjuseid URI-de muutmiseks (või dokumentide haldamise lõpetamiseks), kuid praktikas on neid miljoneid.

Teoreetiliselt on domeeninime nominatiivne omanik tõeliselt domeeninime ruumi omanik ja seega kõikide URI-de omanik selles osas. Ainult maksejõuetuse korral ei takista miski domeeninime omanikul seda nime hoida. Teoreetiliselt on teie domeeninime all olev URI ruum täielikult teie kontrolli all, nii et saate teha selle nii stabiilseks, kui soovite. Suures osas on ainus kaalukas põhjus, miks dokument Internetist puudub, see, et domeeninime omanik firma on pankrotis või ei suuda enam serveri tööd toetada. Miks on siis maailmas nii palju kadunud linke? Osaliselt on see lihtsalt ettenägemise puudumine. Siin on mõned põhjused, mida võib kuulda:

Me lihtsalt reorganiseerisime veebisaidi, et muuta see paremaks.

Kas tõesti arvate, et vanad URI-d ei saa enam töötada? Kui jah, siis olete need väga halvasti valinud. Mõelge sellele, et uued püsiksid ka järgmisel redigeerimisel.

Meil on nii palju materjali, et me ei suuda jälgida, mis on aegunud, mis on konfidentsiaalne ja mis on endiselt oluline, seetõttu arvasime, et oleks parem see kõik lihtsalt välja lülitada.

Võin ainult kaasa tunda. W3C on üle elanud perioodi, mil pidime hoolikalt läbi vaatama arhiivimaterjalid, et kontrollida nende konfidentsiaalsust, enne kui need avalikkusele kätte anda. Otsus peab olema hoolikalt läbi mõeldud — veenduge, et igas dokumendis fikseerite sobiva lugejaskonna, loomise kuupäeva ja ideaaljuhul kehtivuse ajavahemiku. Hoidke neid metaandmeid.

Noh, me avastasime, et failid tuleb ümber paigutada…

See on üks kõige armetumaid vabandusi. Paljud ei tea, et veebiserverid võimaldavad teil hallata seoseid objekti URI ja selle tegeliku asukoha vahel failisüsteemis. Kujutage ette URI ruumi kui abstraktset ruumi, mis on ideaalselt organiseeritud. Seejärel kaardistage see igasugusele reaalsusele, mida te tegelikult selle rakendamiseks kasutate. Siis andke sellest veebiserverile teada. Saate isegi kirjutada oma serveri fragmenti, et kõik õigesti teha.

John ei toeta enam seda faili, nüüd teeb seda Jane.

Kas Johni nimi oli URI-s? Ei, lihtsalt fail oli tema kataloogis? Selge.

Varem kasutasime selle jaoks CGI-skripti, nüüd kasutame binaarprogrammi.

On kummaline idee, et skriptidega loodud lehed peaksid olema "cgibin" või "cgi" alal. See paljastab, kuidas te oma veebiserverit käitate. Muudate mehhanismi (isegi kui sisu jääb samaks) ja ups — kõik teie URI-d muutuvad.

Võtame näiteks Rahvusliku Teadusfondi (NSF):

NSF veebidokumendid

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

Esimene leht dokumentide vaatamiseks ei jää kindlasti pärast paar aastat samaks. cgi-bin, oldbrowse ja pl — kõik see annab teavet selle kohta, kuidas-me-kuidas-teeme-seda. Kui aga kasutate lehte dokumendi otsimiseks, siis saate esimese tulemuse sama halva:

Krüptoloogia ja kodeerimisteooria töögrupi aruanne

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

dokumentide indeksileht, kuigi html-dokument ise näeb palju parem välja:

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

Siin on pealkiri pubs/1998, mis annab igasugusele tulevasele arhiiviteenusele hea arusaamise 1998. aasta dokumentide klassifikatsiooniskeemidest. Ehkki 2098. aastal võivad dokumentide numbrid välja näha erinevad, ei kujuta ma ette, et see URI ei ole endiselt kehtiv ning see ei häiriks NSF-i ega ühtegi muud organisatsiooni, kes arhüüvi haldab.

Ma ei arvanud, et URL-id peavad olema püsivad — ju oli ju URN.

Tõenäoliselt on see üks halvimatest kõrvalmõjudest URN-i arutelul. Some arvavad, et kuna uurimused püsivamate nimetuste ruumide kohta, võivad nad kobamisi suhtuda rippuvatesse linkidesse, kuna 'URN teeb kõik korda'. Kui sa oled üks neist inimestest, siis lase mul sind petta.

Enamik URN skeeme, mida olen näinud, näevad välja nagu autoriteedi identifikaator, millele järgneb kas kuupäev ja rida, millest te valite, või lihtsalt rida, millest te valite. See on väga sarnane HTTP URI-le. Teisisõnu, kui arvate, et teie organisatsioon suudab luua pikaealisi URN-e, siis tõestage 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õmbamiseks.

Kui olete siiani jõudnud, siis kui teil ei ole aega, raha ja kontakte, et arendada mingit tarkvara, võite esitada järgmise vabanduse:

Me tahtsime, aga meil pole lihtsalt vajalikke tööriistu.

Seda on tõeliselt kahetsusväärne. Ma olen täiesti nõus. Kõik, mida peate tegema, on sundida veebiserverit viivitamatult töötlema püsivat URI-d ja tagastama faili, kus iganes see teie praeguses kaootilises failisüsteemis hetkel asub. Soovite salvestada kõik URI-d faili kontrollimiseks ja pidevalt hoida andmebaasi ajakohasena. Soovite säilitada suhteid erinevate versioonide ja sama dokumendi tõlgete vahel ning hoida sõltumatut kontrollsummade kirjet, et tagada faili kaitse juhusliku rikke eest. Ning veebiserverid ei tule lihtsalt nende funktsioonidega karbist välja. Kui soovite luua uut dokumenti, palub teie redaktor määrata URI.

Teil on vaja võimalust muuta omandit, juurdepääsu dokumentidele, arhiveerimise taseme turvalisust ja muud URI ruumis ilma URI-d muutmata.

Asjad on liiga halvad. Kuid me parandame olukorra. W3C-s kasutame me Jigedit funktsionaalsust (Jigsaw server dokumendi redigeerimiseks), mis jälgib versioone, ja katsetame dokumentide loomise skripte. Kui arendate tööriistu, servereid ja kliente, võtke seda teemat tõsiselt!

See vabandus kehtib ka paljudele W3C lehtedele, sealhulgas sellele: tehke seda, mida ma ütlen, mitte seda, mida ma teen.

Miks peaks see mind huvitama?

Kui muudate URI oma serveris, ei saa te kunagi täielikult teada, kellel on lingid vana URI-le. Need võivad olla lingid tavaliselt veebilehtedelt. Raamatupidamised teie lehele. URI võis olla kirjutatud sõbra kiri servale.

Kui keegi klikib lingile ja see on katki, kaotab ta tavaliselt usalduse serveri omaniku vastu. Ta tunneb samuti pettumust — nii emotsionaalselt kui ka reaalselt, kui ei suuda oma eesmärki saavutada.

Paljud inimesed kaebavad pidevalt katki linkide üle ja ma loodan, et kahju on ilmne. Loodan, et ka mainekahju serveri hooldajatusele, kust dokument kadunud on, on samuti ilmne.

Nii et mida ma peaksin tegema? URI kujundus

See on veebi arendaja kohustus — välja tuua URI-d, mida saab kasutada kahe aasta, kahekümne aasta või kahekümne aasta pärast. Selleks on vajalik läbimõeldus, organiseeritus ja sihikindlus.

URI-d muutuvad, kui neis sisalduv teave muutub. On väga oluline, kuidas te neid projekteerite. (Mida, URI disain? Kas ma pean URI-d projekteerima? Jah, te peaksite sellele mõtlema). Projekteerimine tähendab peamiselt seda, et URI-s ei ole mingit teavet.

Dokumendi loomise kuupäev — URI väljastamise kuupäev — on asjaolu, mis ei muutu kunagi. See on väga kasulik, et eristada päringuid, mis kasutavad uut süsteemi, neist, mis kasutavad vana süsteemi. Sellel on hea alustada URI-d. Kui dokumendil on mõni kuupäev märgitud, isegi kui dokument on tulevikus asjakohane, on see hea algus.

Ainus erand on leht, mis on meelega «viimane» versioon, näiteks kogu organisatsiooni või suure osa jaoks.

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

See on viimane Money Daily veerg Money ajakirjas. Peamine põhjus, miks selles URI-s pole kuupäeva, on see, et pole mingit põhjust säilitada URI-d, mis kestab kauem kui ajakiri. Konseptsioon Money Daily kaob koos Money-ga. Kui soovite sisu käsitleda, tuleks seda eraldi viidata arhiivides:

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

(Näeb hea välja. Eeldab, et "raha" tähendab kogu aeg sama asja pathfinder.com-i eksistentsi vältel. On duplikaate "98" ja üleliigne ".html", kuid muidu näeb välja tugev URI.

Mida kõrvale jätta

Kõik! Lisaks loomiskuupäevale, kui panete mingit teavet URI-sse, otsite te nii või naa probleme.

• Autori nimi. Autorsus võib muutuda uute versioonide tulekuga. Inimesed lahkuvad organisatsioonidest ja edastavad asjad teistele.
• Teema. See on väga keeruline. See näeb esialgu alati hea välja, kuid see muutub üllatavalt kiiresti. Räägin sellest lähemalt allpool.
• Staatus. Kataloogid nagu "vana", "mustand" ja nii edasi, rääkimata "viimasest" ja "ägedast", ilmuvad kõigis failisüsteemides. Dokumentide staatust muudetakse — muidu ei oleks mõtet mustandeid luua. Viimane versioon dokumendist vajab pidevat identifikaatorit, sõltumata selle staatusest. Hoidke staatus väljaspool nime.
• Ligipääs. W3C-s oleme jaganud veebilehe osadeks töötajatele, liikmetele ja avalikkusele. See kõlab hästi, kuid muidugi algavad dokumendid töötajate meeskonna ideedest, arutatakse liikmetega ja seejärel muutuvad need avalikkuse pärandiks. On tõeliselt kurb, kui iga kord, kui mõni dokument avatakse laiemaks aruteluks, kõik vanad lingid sellele purunevad! Nüüd liigume lihtsa kuupäevakoodi juurde.
• Faili laiend. Väga levinud nähtus. "cgi", isegi ".html" muutuvad tulevikus. Võib-olla 20 aasta pärast ei kasuta te HTML-i sellele leheküljele, kuid tänased lingid sellele peaksid ikka toimima. W3C saidil ei kasutata kanonilisi linke laiendit (kuidas see toimub).
• Programmi mehhanismid. URI-s otsi otsige "cgi", "exec" ja muid termineid, mis karjuvad "vaadake, millist tarkvara me kasutame". Kas keegi soovib pühendada kogu oma elu Perl CGI skriptidele? Ei? Siis eemaldage .pl laiend. Loe serveri juhendit, kuidas seda teha.
• Detaile nimi. Oh come on! Aga ma olen seda näinud.

Nii et parim näide meie saidilt on lihtsalt

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

… W3C esimeeste koosoleku protokoll.

Teemad ja klassifikatsioon teemade kaupa

Räägin sellest ohust lähemalt, sest see on üks neist asjadest, mida on kõige raskem vältida. Reeglina satuvad teemad URI-sse, kui klassifitseerite oma dokumente läbiviidava töö kaupa. Kuid see jaotus muutub aja jooksul. Alade nimed muudavad. W3C-s tahtsime muuta MarkUP Markup-iks, seejärel HTML-iks, et kajastada jaotise tegelikku sisu. Lisaks on siin sageli tasane nimesüsteem. 100 aasta pärast olete kindlad, et ei soovi midagi uuesti kasutada? Oma lühikese elu jooksul oleme juba soovinud uuesti kasutada "Ajalugu" ja "Stiililehed", näiteks.

See on ahvatlev viis veebisaidi korraldamiseks — ja tõeliselt ahvatlev viis igasuguste asjade korraldamiseks, sealhulgas kogu Interneti jaoks. See on suurepärane keskpikaajaline lahendus, kuid pikaajaliselt on sellel tõsised puudused.

Osaliselt on põhjused peidus tähenduse filosoofias. Iga termin keeles on potentsiaalne klasterdamise objekt, ja igal inimesel võib olla erinev arusaam sellest, mida see tähendab. Kuna suhteid subjektide vahel on rohkem nagu ämblikuvõrk kui puu, võivad isegi need, kes nõustuvad võrguga, valida teistsuguse puu esinduse. Need on minu (sageli korduvad) üldised märkused hierarhilise klassifitseerimise ohtudest kui üldisest lahendusest.

Tegelikult, kui kasutate teema nime URI-s, sidute end mingisuguse klassifikatsiooniga. Võib-olla eelistate tulevikus teistsugust varianti. Siis on URI riknemise oht.

Teematüübi kasutamine URI osana on tingitud sellest, et URI alamvaldkondade eest vastutus delegeeritakse tavaliselt, mistõttu on vajalik organisatsioonilise üksuse nimi — osakond, rühm või miski muu, mis vastutab selle allüksuse eest. See sidestab URI organisatsioonilise struktuuriga. See on tavaliselt ohutu ainult siis, kui URI on edaspidi (vasakul) kaitstud kuupäeva järgi: 1998/pics võib teie serverile tähendada "seda, mida me 1998. aastal pics'i all silmas pidasime", mitte "seda, mida me 1998. aastal tegime selle kohta, mida nüüd nimetame pics'iks."

Ärge unustage domeeninime

Pange tähele, et see kehtib mitte ainult URI tee, vaid ka serveri nime kohta. Kui teil on erinevad serverid erinevate asjade jaoks, pidage meeles, et seda eristust ei saa muuta, hävitamata palju, palju linke. Mõned klassikalised vead, nagu "vaadake, millist tarkvara me täna kasutame" — domeeninimed "cgi.pathfinder.com", "secure", "lists.w3.org". Need on loodud serverite haldamise lihtsustamiseks. Ükskõik, kas domeen esindab mõnda teie ettevõtte osakonda, dokumendi staatust, juurdepääsu taset või turvalisust, olge väga, väga ettevaatlik, enne kui kasutate rohkem kui ühte domeeninime mitme dokumentide tüübi jaoks. Pidage meeles, et saate peita mitmeid veebiservereid ühe nähtava veebiserveri sisse, kasutades suunamist ja vahetusmehhanisme.

Jah, ja mõelge ka oma domeeninimele. Te ei soovi, et teid viidatakse kui soap.com pärast seda, kui olete tootmisliini muutnud ja lõpetanud seebi tootmise (palun vabandust selle üle, kes hetkel soap.com'i omab).

Kokkuvõte

URI säilitamine 2, 20, 200 või isegi 2000 aastat ei ole kindlasti nii lihtne, kui esmapilgul tundub. Sellegipoolest teevad veebihaldurid kogu internetis otsuseid, mis teevad tulevikus selle ülesande endale tõeliselt raskeks. Sageli juhtub see sellepärast, et nad kasutavad tööriistu, mille eesmärk on esitada parim sait just praegu – ning keegi ei ole hinnanud, mis juhtuma hakkab linkidega, kui kõik muutub. Kuid siinkohal on oluline mõista, et palju, väga palju võib muutuda, ja teie URI-d võivad ja peavad jääma samaks. See on võimalik ainult siis, kui te mõtletemis moodi te need loote.

Vaata ka:

• Jakob Nielseni tirade sama teema kohta

Täiendused

Kuidas eemaldada faili laiendeid...

…URI-st praeguses veebiserveris failide põhjal?

Kui kasutate näiteks Apache'i, siis saate seda seadistada sisu vastavusse viimiseks. Hoidke faili laiend (nt .png) failis (nt, mydog.png), kuid viitamine veebiallikale on võimalik ka ilma selleta. Seejärel kontrollib Apache katalooge, et leida kõik failid selle nime ja igasuguste laienditega, samuti võib valida parima komplekti (näiteks GIF ja PNG). Erinevaid failitüüpe ei pea tõepoolest eraldi kataloogides hoidma, tõeliselt ei toimi sisu kooskõla, kui te nii teete.

• Seadistage oma server sisu kooskõla jaoks
• Viidake alati URI-dele ilma laiendita

Viidatud laienditega lingid töötavad endiselt, kuid ei võimalda teie serveril valida parimat hetkel ja tulevikus saadaval olevat formaati.

(Tegelikult, mydog, mydog.png ja mydog.gif — kehtivad veebiallikad, mydog — see on universaalse sisu tüübi allikas, ja mydog.png ja mydog.gif — spetsiifilise sisu tüübi allikad).

Loomulikult, kui kirjutate oma veebiserveri, on hea kasutada andmebaasi püsivate tuvastajate sidumiseks nende praeguse vormiga, kuigi hoiduge piiramatu andmebaasi kasvust.

Veebipaneel — Lugu 1: Channel 7

Aasta 1999 jooksul jälgisin ma koolide sulgemist lume tõttu lehe kaudu http://www.whdh.com/stormforce/closings.shtml. Ei saa ju oodata, et teave ilmub televiisori ekraani alla! Panin sellele lingi oma kodulehelt. Esimene suur lumetorm aastal 2000 tuleb ja kontrollin lehte. Seal on kirjas:

— Seisuga.
Praegu pole midagi suletud. Palun tulge tagasi, kui ilmastikutingimustes on hoiatusi.

Ei saa olla, et selline tugev torm. Naljakas, et kuupäev puudub. Kuid kui minna veebisaidi avalehele, siis on seal suur nupp „Sulete koolid”, mis viib lehele http://www.whdh.com/stormforce/ pikast suletud koolide nimekirjast.

Võib-olla muutsid nad nimekirja hankimise süsteemi — aga nad ei pidanud muutma URI-d.

Ahnuse tahvel — Lugu 2: Microsoft Netmeeting

Kuna sõltuvus internetist kasvab, tuli hea mõte, et rakendustesse saab lisada tootja veebisaidi linke. Seda kasutati sageli ja kuritarvitati, kuid — URL-i ei tohi muuta. Just paar päeva tagasi proovisin linki Microsoft Netmeeting 2/what ever menüüs Help/Microsoft on the Web/Free stuff ja sain 404 vea — server ei leidnud vastust. Võib-olla on nad juba probleemi lahendanud...

©1998 Tim BL

Ajalooline märkustus: 20. sajandi lõpus, kui see kirjutati, oli «lahe» kiiduväärne epiteet, eriti noorte seas, viidates moodsaile, kvaliteetsetele või asjakohastele asjadele. Kiirusel valiti URI-d sageli «laheduse» järgi, mitte kasulikkuse või vastupidavuse järgi. See märkuse on katse suunata energiat, mis seisneb laheduse otsimises.

Allikas: habr.com