Autor — sir Tim Berners-Lee, URI, URL, HTTP, HTML ja WWW leiutaja, W3C tegevjuht. Artikkel on kirjutatud 1998. aastal

Millist URI võib pidada "lahedaks"?
Sellist, mis ei muutu.
Kuidas URI-d muutuvad?
URI-d ei muutu: neid muudavad inimesed.

Ideeliselt ei peaks inimestel olema mingeid põhjuseid URI-de muutmiseks (või dokumentide toetamise lõpetamiseks), kuid praktikas on neid miljoneid.

Teoreetiliselt omab nimeline domeeniruumi omanik tõeliselt domeeniruumi ja seega kõiki URI-sid selles. Välja arvatud maksejõuetuse korral ei takista miski domeeni omaniku nime hoidmist. Ja teoreetiliselt on teie domeeninime all olev URI ruum täielikult teie kontrolli all, nii et saate seda muuta nii stabiilseks, kui soovite. Peamine põhjus dokumendi kadumiseks internetist on, et domeeni omav ettevõte on lõpetanud tegevuse või ei suuda enam serverit toetada. Miks on maailmas nii palju kadunud linke? Osaliselt on see lihtsalt ettevaatamatuse puudumine. Siin on mõned põhjused, mida võib kuulda:

Me lihtsalt reorganiseerisime veebilehte, et teha see paremaks.

Kas tõesti arvate, et vanad URI-d ei saa enam töötada? Kui jah, siis valisite need väga halvasti. Mõelge, kuidas need saaksid pärast järgmist uuendamist säilida.

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

Võin vaid kaastundlikult nõustuda. W3C on kogenud perioodi, mil pidime hoolikalt läbivalima arhiivimaterjale privaatsete andmete osas, enne kui need avalikuks teha. Otsused tuleb teha ettevaatlikult – veenduge, et salvestate iga dokumendi soovitud lugejate ringi, loomise kuupäeva ja ideaaljuhul ka kehtivuse tähtaega. Säilitage need metaandmed.

Noh, me avastasime, et failide liigutamine on vajalik...

See on üks kõige haledamaid õigustusi. Paljud ei tea, et veebiserverid võimaldavad juhtida seost URI objekti ja selle tegeliku asukoha vahel failisüsteemis. Kujutage ette URI ruumi kui abstraktset ruumi, mis on ideaalselt korraldatud. Seejärel tehke kaardistus igasugusele reaalsusele, mida te tegelikult selle rakendamiseks kasutate. Siis teavitage sellest veebiserverit. Te võite isegi kirjutada oma serveri fragmenti, et kõik õigesti toimida.

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

Kas Johns nimi oli URI-s? Ei, lihtsalt fail asus tema kataloogis? No selge.

Varem kasutasime selle jaoks CGI-skripti, aga nüüd kasutame binaarset programmi.

On hullumeelne idee, et skriptidega loodud lehed peaksid olema paigutatud "cgibin" või "cgi" piirkonda. See paljastab, kuidas te oma veebiserverit käivitate. Muutke mehhanismi (isegi kui sisu jääb samaks) ja oop – kõik teie URI-d muutuvad.

Võtame näiteks Ameerika Ühendriikide Rahvuslik Teadusfond (NSF):

NSF veebidokumendid

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

Esimene leht dokumentide vaatamiseks ei jää ilmselt selliseks mõne aasta pärast. cgi-bin, oldbrowse ja pl — kõik see annab teavet, kuidas-me-seda-teeme-kuidagi. Kui te aga kasutate lehte dokumendi leidmiseks, saate esimesena sama halva tulemuse:

Krüptograafia ja kooditeooria töörühma aruanne

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

dokumendi indeksilehe jaoks, kuigi HTML-dokument ise näeb palju parem välja:

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

Siin pealkiri pubs/1998 annab igale tulevikule arhiveerimisteenusele hea võtme, et mõista, kuidas toimib vana dokumendi klassifitseerimiskeem 1998. aastast. Kuigi 2098. aastal võivad dokumendi numbrid välja näha teisiti, usun, et see URI on endiselt kehtiv ning see ei takista NSF-i ega ühtegi muud organisatsiooni, kes archiivi haldavad.

Ma ei arvanud, et URL-id peaksid olema püsivad – olid ju olemas URN-id.

See on tõenäoliselt üks halvim kõrvalmõju URN-ide arutelu puhul. Mõned arvavad, et kuna uuritakse püsivama nimeruumi teemadel, võivad nad liikvel linkide osas hooletud olla, kuna "URN lahendab selle kõik". Kui olete üks neist inimestest, siis lubage mul teid pettumust valmistada.

Enamik näiteid URN scheemidest, mida olen näinud, näevad välja nagu autoriteedi identifikaator, millele järgneb kas kuupäev ja valitud string või lihtsalt valitud string. See sarnaneb väga HTTP URI-le. Teisisõnu, kui arvate, et teie organisatsioon suudab luua pikaajalisi URN-e, siis tõestage 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õmbamiseks.

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

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

Sellele saab tõeliselt kaasa tunda. Olen täielikult nõus. Mida peate tegema, on sundida veebiserverit koheselt töötlema püsivat URI-d ja tooma faili, olenemata sellest, kus see hetkel teie praeguses hullumeelses failisüsteemis asub. Soovite hoida kõiki URI-sid failis kontrollimiseks ja pidevalt päeva peal olevat andmebaasi. Soovite säilitada seoseid erinevate versioonide ja tõlgete vahel ühe ja sama dokumendi vahel, samuti säilitada sõltumatu kontrollsummade salvestus, et kaitsta faili kahjustumise eest juhuslike vigade tõttu. Ja veebiserverid ei ole lihtsalt valmis nende funktsioonidega. Kui soovite luua uue dokumendi, palub teie toimetaja määrata URI.

Teil on vaja võimalust muuta omandit, dokumentidele juurdepääsu, arhiivi turvatasemete taset jms URI ruumis ilma URI-d muutmata.

Kõik on liiga halb. Aga me parandame selle. W3C-s kasutame me Jigedit funktsionaalsust (Jigsaw server redigeerimise jaoks), mis jälgib versioone, ja katsetame dokumentide loomise skripte. Kui arendate tööriistu, servereid ja kliente, pöörake sellele probleemile tähelepanu!

See õigustus kehtib ka paljude W3C lehtede kohta, sealhulgas selle kohta: nii et tehke seda, mida ma ütlen, mitte seda, mida ma teen.

Miks peaks see mind huvitama?

Kui muudad URI oma serveris, ei saa sa kunagi täielikult öelda, kellel on lingid vana URI peale. Need võivad olla lingid tavalistelt veebilehtedelt. Suhtlemisvihikud sinu lehe kohta. URI võidi olla kirjutatud sõbra kirjale servale.

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ärki.

Paljud inimesed kaebavad pidevalt rikutud linkide üle ja loodan, et kahju on ilmne. Loodan, et samuti on ilmne mainekahju serveri haldajale, kus dokument kadus.

Mis ma peaksin tegema? URI kavandamine.

See on veebimeistri kohustus välja valida URI-d, mida saab kasutada kahe aasta, kahekümne aasta või kaheaasta jooksul. Selleks on vajalikud hoolivus, organiseeritus ja sihikindlus.

URI-d muutuvad, kui neis muutub mingi teave. On väga oluline, kuidas sa neid kavandad. (Mida, URI kavandamine? Ma pean kavandama URI-d? Jah, sa pead sellele mõtlema). Kavandamine tähendab peamiselt selle puudumist URI-s.

Dokumendi loomise kuupäev - URI väljastamise kuupäev - on see, mis ei muutu kunagi. See on väga kasulik erinevate päringute eristamiseks, mis kasutavad uut süsteemi, vanast süsteemist. Sellega on hea alustada URI-d. Kui dokumendil on mingi kuupäev, isegi kui dokument jääb tulevikus asjakohaseks, on see hea algus.

Ainus erand on leht, mis on teadlikult 'lõplik' versioon, näiteks kogu organisatsiooni või suure osa jaoks.

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

See on Money Daily viimane veerg ajakirjas Money. Peamine põhjus, miks selles URI-s ei ole vajalik kuupäev, on see, et ei ole mingeid põhjuseid säilitada URI-d, mis ületab ajakirja. Rahanduse mõisted kaovad koos rahaga. Kui soovite viidata sisule, peaksite viitama sellele eraldi arhiivides:

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

(Näeb hea välja. Eeldab, et "money" tähendab pathfinder.com-i jooksul sama. On dubleerimine "98" ja tarbetu ".html", kuid muidu tundub see tugev URI.

Mida kõrvale jätta.

Kõik! Lisaks loomiskuupäevale, kui paned mistahes teabe URI-sse, kutsub see paratamatult esile probleeme.

• Autori nimi. Autoriteet võib muutuda uute versioonide tulekuga. Inimesed lahkuvad organisatsioonidest ja annavad asjad üle teistele.
• Teema. See on väga keeruline. Esialgu näeb see alati hästi välja, kuid muutub üllatavalt kiiresti. Räägin sellest allpool lähemalt.
• Staatus. Kataloogid nagu „vana”, „mustand” jne, rääkimata „viimase” ja „laheda” puhul, ilmuvad kõikides failisüsteemides. Dokumentide staatust muudetakse — vastasel juhul ei oleks mõtet mustandeid luua. Viimase versiooni dokument vajab pidevat identifikaatorit, sõltumata selle staatuse muutumisest. Hoidke staatus nime alt eemal.
• Juurdepääs. W3C-s oleme jaganud saidi alajaotusteks töötajatele, liikmetele ja avalikkusele. See kõlab hästi, kuid loomulikult algavad dokumentide toimetused töötajate ideedest, arutatakse liikmete seas ja muutuvad seejärel üldiseks. On tõeliselt vale, kui iga kord, kui mingi dokument avatakse laiemaks aruteluks, katkeb kõik senised lingid sellele! Nüüd liigume lihtsa kuupäeva koodi 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 selle lehe jaoks, kuid tänased lingid sellele peavad siiski tööle jääma. W3C saidi kanonilised lingid ei kasuta laiendit (kuidas see käib).
• Programmikeeramismehhanismid. URI-s otsige "cgi", "exec" ja muid termineid, mis karjuvad: „vaadake, millist tarkvara me kasutame”. Kas keegi sooviks oma elu pühendada Perl CGI skriptide kirjutamisele? Ei? Siis eemaldage laiend .pl. Vaadake serveri juhendit, kuidas seda teha.
• Diskinimi. Oh tule nüüd! 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 protokolli aruanne.

Teemad ja teema klassifikatsioon

Rohkem räägin sellest ohust, kuna see on üks neist asjadest, mida on kõige raskem vältida. Üldiselt satuvad teemad URI-sse, kui klassifitseerite oma dokumente nende täitmise alusel. Kuid see jaotus muutub aja jooksul. Valdkondade nimed muutuvad. W3C-s soovisime muuta MarkUP Markupiks ja seejärel HTML-iks, et peegeldada jaotise tegelikku sisu. Lisaks on siin sageli lame nime ruum. 100 aasta pärast olete kindel, et ei soovi midagi uuesti kasutada? Meie lühikese elu jooksul oleme juba soovinud uuesti kasutada „Lugu“ ja „Stiililehed“, näiteks.

See on ahvatlev viis veebisaidi korraldamiseks – ja tõeliselt ahvatlev viis mis iganes korraldamiseks, sealhulgas kogu võrgu korraldamiseks. See on suurepärane keskmise aja lahendus, kuid omab tõsiseid puudusi pikaajalises perspektiivis.

Osaliselt on põhjused seotud mõttefilosoofiaga. Iga termin keeles on potentsiaalne klasterdamise objekt ja igaühel võib olla erinev arusaam sellest, mida see tähendab. Kuna subjektide vahelised suhted on pigem nagu veeb kui puu, võivad isegi need, kes nõustuvad veebiga, valida puu teise esituse. Need on minu (tihti korduvad) üldised märkused hierarhilise klassifitseerimise ohtude kohta kui üldise lahenduse.

Tegelikult, kui kasutate teema nime URI-s, sidute end mingi klassifikatsiooniga. Võib-olla eelistate tulevikus muud varianti. Sel juhul on URI rikkuv.

Teema ala kasutamise põhjus URI osana on see, et vastutus URI ruumi alamalade eest delegeeritakse tavaliselt ja siis on teil vaja organisatsioonilise organi nime – osakonna, grupi või midagi muud, mis vastutab selle ala eest. See on URI sidumine organisatsioonilise struktuuriga. See on tavaliselt ainult siis ohutu, kui URI on kaitstud kuupäevaga: 1998/pics võib teie serverile tähendada „see, mida me mõtlesime 1998. aastal pics'i all“, mitte „see, mida me 1998. aastal tegime sellega, mida nüüd nimetame pics'iks“.

Ärge unustage domeeninime

Pidage meeles, et see kehtib mitte ainult URI teele, vaid ka serveri nimele. Kui teil on eraldi serverid erinevate tegevuste jaoks, pidage meeles, et see jaotus on keeruline muuta, ilma et kaotaks palju ja palju linke. Klassikalised vead nagu "vaatake, 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 haru, dokumendi staatust, juurdepääsu taset või turvataset, olge väga, väga ettevaatlikud, enne kui kasutate enam kui ühte domeeninime mitmesuguste dokumentide jaoks. Pidage meeles, et saate peita mitmeid veebiservereid ühe nähtava veebiserveri sisse, kasutades suunamisi ja proksingut.

Jah, ja mõelge ka oma domeeninimele. Te ei taha, et teid viidataks kui soap.com pärast seda, kui te muudate oma tootevalikut ja lõpetate seebi tootmise (Kahjuks sellele, kes praegu soap.com'i omab).

Kokkuvõte

URI säilitamine 2, 20, 200 või isegi 2000 aastat ei ole ilmselgelt nii lihtne, kui tundub. Siiski, kogu internetis teevad veebimeistrid otsuseid, mis muudavad selle ülesande endale tulevikus tõeliselt keeruliseks. Tihti juhtub see seetõttu, et nad kasutavad tööriistu, mille eesmärk on esitada parim veebisait ainult hetkel — ja keegi ei ole arvestanud, mis juhtub linkidega, kui kõik muutub. Siiski, mõttepunkt on see, et palju, väga palju võib muutuda, ja teie URI-d võivad ja peaksid jääma samaks. See on võimalik ainult siis, kui mõtlete, kuidas te neid loote.

Vaata ka:

• Jakob Nielseni tirade sama teema kohta

Lisa

Kuidas eemaldada faililaiendid...

...URI-st jooksvas veebiserveris failide põhjal?

Kui kasutate näiteks Apache't, saate selle seadistada sisu kokkulangevuseks. Hoidke faililaiend (näiteks .png) failis (nt, mydog.png), kuid viidatud veebiallikale saab ju viidata ka ilma selleta. Seejärel kontrollib Apache katalooge, et leida kõiki faile selle nime ja mis tahes laiendiga, samuti võib ta valida parima komplekti (näiteks GIF ja PNG). Ja ei ole vaja paigutada erinevaid faili tüüpe erinevatesse kataloogidesse, tegelikult ei toimi sisu ühtlustamine, kui te seda teete.

• Seadistage oma server sisu ühtlustamiseks
• Alati viidake URI-le ilma laiendita

Laiendiga 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 universaalne sisu tüüp, samas kui mydog.png ja mydog.gif — on kindla sisu tüübiga allikad).

Muidugi, kui te kirjutate oma veebiserveri, siis on hea kasutada andmebaasi, et siduda püsivad identifikaatorid nende praeguse vormiga, kuigi vältige andmebaasi piiramatu kasvu.

Kohutav nöör — Lugu 1: Channel 7

1999. aastal jälgisin, kuidas koolide sulgemine seoses lumega toimetati lehe peal, http://www.whdh.com/stormforce/closings.shtml. Ei ole ju mõtet oodata, kuni teave ekraani allossa ilmub! Lisasin sellele lingi oma kodu lehelt. Tuli 2000. aasta esimene suur lumetorm ja ma kontrollisin lehte. Seal oli kirjutatud:

— Seisuga.
Praegu ei ole midagi suletud. Palun tulge tagasi ilmastikuteadete korral.

Ei saa olla, sama tugev torm. Naljakas, et kuupäeva ei ole. Kuid kui minna veebisaidi kodulehele, on seal suur nupp "Sulgemiseks koolid", mis viib lehele http://www.whdh.com/stormforce/ pikema sulgemise koolide nimekirjaga.

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

Kohutav nöör — Lugu 2: Microsoft Netmeeting

Interneti sõltuvuse kasv tuli nutikas mõte, et rakendustesse võiks inteerida tootja veebilehe lingid. Seda kasutati sageli ja kuritarvitati, kuid URL-i ei tohi muuta. Just paar päeva tagasi proovisin linki klient Microsoft Netmeeting 2/something menüüs Alopeedia/Microsoft veebis/Vaba kraam ja sain 404 vea — server ei leidnud vastust. Võib-olla on juba parandatud…

©1998 Tim BL

Ajalooline märk: 20. sajandi lõpus, kui see kirjutati, oli "lahe" heakskiitva kuvandi epiteet, eriti noorte seas, mis viitas moodusele, kvaliteedile või asjakohasusele. Kiirusest tingituna valiti sageli URI tee "laheduse" järgi, mitte kasulikkuse või kestvuse järgi. See märkus on katse suunata energiat, mis seisab laheduse otsimise taga.

Allikas: habr.com