Autor: Sir Tim Berners-Lee, URI-de, URL-ide, HTTP, HTML-i ja World Wide Webi leiutaja ning praegune W3C juht. Artikkel on kirjutatud 1998. aastal

Millist URI-d peetakse lahedaks?
Üks, mis ei muutu.
Kuidas URI-sid muudetakse?
URI-d ei muutu: inimesed muudavad neid.

Teoreetiliselt pole inimestel põhjust URI-sid muuta (või lõpetada tõendavate dokumentide esitamine), kuid praktikas on neid miljoneid.

Teoreetiliselt omab domeeni nimeruumi nominaalne omanik tegelikult domeeni nimeruumi ja seega kõiki selles olevaid URI-sid. Peale maksejõuetuse ei takista miski domeeninime omanikul nime endale jäämast. Ja teoreetiliselt on teie domeeninime all olev URI-ruum täielikult teie kontrolli all, nii et saate muuta selle nii stabiilseks kui soovite. Peaaegu ainus hea põhjus, miks dokument Internetist kaob, on see, et domeeninime omanud ettevõte on tegevuse lõpetanud või ei saa enam serveri töös hoida. Miks on siis maailmas nii palju puuduvaid lülisid? Osa sellest on lihtsalt ettenägelikkuse puudumine. Siin on mõned põhjused, mida võite kuulda.

Korraldasime saidi lihtsalt ümber, et seda paremaks muuta.

Kas sa tõesti arvad, et vanad URI-d ei saa enam töötada? Kui jah, siis valisite need väga halvasti. Kaaluge uute allesjätmist järgmise ümberkujundamise jaoks.

Meil on nii palju asju, et me ei suuda jälgida, mis on aegunud, mis on konfidentsiaalne ja mis on endiselt asjakohane, mistõttu pidasime paremaks see kõik lihtsalt välja lülitada.

Võin ainult kaasa tunda. W3C läbis perioodi, mil pidime enne nende avalikustamist hoolikalt läbi sõeluma arhiivimaterjalid konfidentsiaalsuse tagamiseks. Otsus tuleks eelnevalt läbi mõelda – veenduge, et iga dokumendi juures oleks kirjas vastuvõetav lugejaskond, loomise kuupäev ja ideaalis aegumiskuupäev. Salvestage need metaandmed.

Noh, avastasime, et peame failid teisaldama...

See on üks haletsusväärsemaid vabandusi. Paljud inimesed ei tea, et veebiserverid võimaldavad teil kontrollida seost objekti URI ja selle tegeliku asukoha vahel failisüsteemis. Mõelge URI-ruumile kui abstraktsele ruumile, mis on täiuslikult organiseeritud. Seejärel tehke kaardistus mis tahes reaalsusele, mida te selle realiseerimiseks tegelikult kasutate. Seejärel teavitage sellest veebiserverit. Selle õigeks muutmiseks võite isegi kirjutada oma serverilõigu.

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

Kas Johni nimi oli URI-s? Ei, kas fail oli ainult tema kataloogis? No okei.

Varem kasutasime selleks CGI skripti, nüüd aga binaarprogrammi.

On hull idee, et skriptide abil loodud lehed peaksid asuma "cgibin" või "cgi" piirkonnas. See paljastab oma veebiserveri käitamise mehhanismid. Muudate mehhanismi (isegi sisu salvestamise ajal) ja oi - kõik teie URI-d muutuvad.

Võtke näiteks National Science Foundation (NSF):

NSF-i veebidokumendid

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

Esimene lehekülg, kust dokumente vaadata, ei jää ilmselgelt mõne aasta pärast samaks. cgi-bin, oldbrowse и pl - kõik see annab teavet selle kohta, kuidas-me-seda-nüüd. Kui kasutate lehte dokumendi otsimiseks, on esimene tulemus sama halb:

Krüptoloogia ja kodeerimise teooria töörühma aruanne

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

dokumendi registrilehe jaoks, kuigi html-dokument ise näeb palju parem välja:

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

Siin annab pubs/1998 päis igale tulevasele arhiiviteenistusele hea aimu, et kehtib vana 1998. aasta dokumentide liigitusskeem. Kuigi dokumendinumbrid võivad 2098. aastal välja näha teistsugused, kujutan ette, et see URI kehtiks endiselt ega segaks NSF-i ega ühtegi muud arhiivi haldavat organisatsiooni.

Ma ei arvanud, et URL-id peavad olema püsivad – seal olid URN-id.

See on ilmselt üks URN-i arutelu halvimaid kõrvalmõjusid. Mõned inimesed arvavad, et püsivama nimeruumi uurimise tõttu võivad nad rippuvate linkide suhtes olla hoolimatud, sest "URN-id parandavad selle kõik." Kui olete üks neist inimestest, lubage mul teile pettumust valmistada.

Enamik URN-skeeme, mida olen näinud, näevad välja nagu volituse identifikaator, millele järgneb kas kuupäev ja teie valitud string või lihtsalt valitud string. See on väga sarnane HTTP URI-ga. Teisisõnu, kui arvate, et teie organisatsioon on võimeline looma pikaealisi URN-e, siis tõestage seda kohe, kasutades neid oma HTTP URI-de jaoks. HTTP-s endas pole midagi, mis muudaks teie URI ebastabiilseks. Ainult teie organisatsioon. Looge andmebaas, mis vastendab dokumendi URN-i praeguse failinimega, ja laske veebiserveril seda kasutada failide tegelikuks toomiseks.

Kui olete selleni jõudnud, kui teil pole aega, raha ja ühendusi mõne tarkvara arendamiseks, võite esitada järgmise vabanduse:

Tahtsime, aga meil pole lihtsalt õigeid tööriistu.

Kuid võite sellele kaasa tunda. Olen täiesti nõus. Peate sundima veebiserverit koheselt püsivat URI-d sõeluma ja faili tagastama kõikjal, kus see teie praeguses hullus failisüsteemis on. Soovite salvestada kõik URI-d faili kontrollina ja hoida andmebaasi kogu aeg ajakohasena. Soovite säilitada seosed sama dokumendi erinevate versioonide ja tõlgete vahel ning säilitada ka sõltumatu kontrollsumma kirje, et tagada, et faili ei rikuta juhusliku vea tõttu. Ja veebiserverid lihtsalt ei tule nende funktsioonidega karbist välja. Kui soovite luua uue dokumendi, palub redaktor teil määrata URI.

URI-ruumis peab saama URI-d muutmata muuta omandiõigust, juurdepääsu dokumentidele, arhiivitaseme turvalisust jne.

See kõik on liiga halb. Aga me parandame olukorra. W3C-s kasutame Jigedit (Jigsaw redigeerimisserveri) funktsionaalsust, mis jälgib versioone, ja katsetame dokumentide genereerimise skriptidega. Kui arendate tööriistu, servereid ja kliente, pöörake sellele probleemile tähelepanu!

See vabandus kehtib ka paljude W3C lehtede kohta, kaasa arvatud see: tehke nii, nagu ma ütlen, mitte nii, nagu ma teen.

Miks ma peaksin hoolima?

Kui muudate oma serveris URI-d, ei saa te kunagi täielikult teada, kellel on lingid vanale URI-le. Need võivad olla lingid tavalistelt veebilehtedelt. Lisa oma leht järjehoidjatesse. URI võis olla sõbrale saadetud kirja veeristele kriimustatud.

Kui keegi järgib linki ja see on katki, kaotab ta tavaliselt usalduse serveri omaniku vastu. Samuti on ta nii emotsionaalselt kui ka füüsiliselt pettunud, kuna ei suuda oma eesmärki saavutada.

Paljud inimesed kurdavad pidevalt katkiste linkide üle ja ma loodan, et kahju on ilmne. Loodan, et ka selle serveri mainekahju, kust dokument kadus, on ilmselge.

Mida ma siis tegema peaksin? URI disain

Veebihaldur vastutab URI-de eraldamise eest, mida saab kasutada 2 aasta, 20 aasta, 200 aasta pärast. See nõuab läbimõeldust, organiseeritust ja sihikindlust.

URI-d muutuvad, kui neis sisalduv teave muutub. See, kuidas te neid kujundate, on väga oluline. (Mis, URI disain? Kas ma pean URI kujundama? Jah, peaksite sellele mõtlema). Disain tähendab põhimõtteliselt igasuguse teabe väljajätmist URI-s.

Dokumendi loomise kuupäev – URI väljastamise kuupäev – ei muutu kunagi. See on väga kasulik uut süsteemi kasutavate päringute eraldamiseks vana süsteemi kasutavatest päringutest. See on hea koht URI-ga alustamiseks. Kui dokument on dateeritud, isegi kui see on tulevikus asjakohane, on see hea algus.

Ainus erand on leht, mis on tahtlikult "uusim" versioon, näiteks kogu organisatsiooni või selle suure osa jaoks.

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

See on ajakirja Money uusim Money Daily veerg. Peamine põhjus, miks selles URI-s kuupäeva pole vaja, on see, et pole põhjust salvestada URI-d, mis logi ületab. Money Daily mõiste kaob, kui raha kaob. Kui soovite sisule linkida, peaksite selle arhiivis eraldi linkima:

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

(Tundub hea. Eeldab, et "raha" tähendab kogu pathfinder.com eluea jooksul sama asja. Seal on duplikaat "98" ja mittevajalik ".html", kuid muidu näeb see välja tugeva URI-na.

Mida kõrvale jätta

Kõik! Peale loomiskuupäeva tekitab igasuguse teabe URI-sse lisamine nii või teisiti probleeme.

• Autori nimi. Autorsus võib muutuda, kui uued versioonid muutuvad kättesaadavaks. Inimesed lahkuvad organisatsioonidest ja annavad asju teistele edasi.
• Teema. See on väga keeruline. See näeb alguses alati hea välja, kuid muutub üllatavalt kiiresti. Ma räägin sellest lähemalt allpool.
• Staatus. Kataloogid nagu "vana", "mustand" ja nii edasi, rääkimata "uusimast" ja "lahe", ilmuvad kõigis failisüsteemides. Dokumendid muudavad staatust – muidu poleks mõtet mustandeid luua. Dokumendi uusim versioon vajab püsivat identifikaatorit, olenemata selle olekust. Hoidke olek nimest väljas.
• Juurdepääs. W3C-s oleme jaganud saidi töötajate, liikmete ja avalikkuse jaoks mõeldud jaotisteks. See kõlab hästi, kuid loomulikult saavad dokumendid alguse töötajate meeskonna ideedest, neid arutatakse liikmetega ja saavad seejärel avalikuks. Oleks tõesti kahju, kui iga kord, kui mõni dokument laiemaks aruteluks avatakse, katkevad kõik selle vanad lingid! Nüüd liigume edasi lihtsa kuupäevakoodi juurde.
• Faililaiend. Väga levinud nähtus. "cgi", isegi ".html" muutub tulevikus. Võib-olla ei kasuta te selle lehe jaoks HTML-i 20 aasta pärast, kuid tänased lingid sellele peaksid siiski töötama. W3C saidi kanoonilised lingid ei kasuta laiendust (kuidas seda tehakse).
• Tarkvara mehhanismid. Otsige URI-st üles "cgi", "exec" ja muud terminid, mis karjuvad "vaadake, millist tarkvara me kasutame". Kas keegi soovib veeta kogu oma elu Perl CGI skripte kirjutades? Ei? Seejärel eemaldage laiend .pl. Kuidas seda teha, lugege serveri kasutusjuhendit.
• Ketta nimi. Ole 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

... aruanne W3C esimeeste koosoleku protokollist.

Teemad ja liigitus teemade kaupa

Ma räägin sellest ohust üksikasjalikumalt, kuna see on üks neist asjadest, mida on kõige raskem vältida. Tavaliselt jõuavad teemad URI-desse, kui kategoriseerite oma dokumendid nende töö järgi. Kuid see jaotus muutub aja jooksul. Piirkondade nimed muutuvad. W3C-s tahtsime muuta MarkUP-iks Markup ja seejärel HTML-i, et kajastada jaotise tegelikku sisu. Lisaks on sageli lame nimeruum. Kas olete kindel, et 100 aasta pärast ei taha te midagi taaskasutada? Oma lühikese elu jooksul oleme juba tahtnud taaskasutada näiteks "Ajalugu" ja "Stiililehti".

See on ahvatlev viis veebisaidi korraldamiseks ja tõeliselt ahvatlev viis korraldada kõike, sealhulgas kogu veebi. See on suurepärane keskmise tähtajaga lahendus, kuid sellel on pikas perspektiivis tõsiseid puudujääke.

Osa põhjusest peitub tähendusfilosoofias. Iga keele termin on rühmitamise potentsiaalne sihtmärk ja igal inimesel võib selle tähendusest olla erinev ettekujutus. Kuna olemitevahelised suhted sarnanevad rohkem võrguga kui puuga, võivad isegi need, kes veebiga nõustuvad, valida puu erineva esituse. Need on minu (tihti korratud) üldised tähelepanekud hierarhilise klassifitseerimise kui üldlahenduse ohtude kohta.

Tegelikult, kui kasutate URI-s teema nime, kohustute end mingisugusele klassifikatsioonile. Võib-olla eelistate tulevikus teist võimalust. URI on siis vastuvõtlik rikkumisele.

Teemavaldkonna kasutamise põhjus URI osana on see, et vastutus URI-ruumi alamjaotiste eest on tavaliselt delegeeritud ja seejärel vajate selle alamruumi eest vastutava organisatsiooniorgani nime – osakond, rühm või mis iganes. See on organisatsiooni struktuuriga siduv URI. Tavaliselt on see turvaline ainult siis, kui edasine (vasakpoolne) URI on kaitstud kuupäevaga: 1998/pics võib teie serverile tähendada pigem seda, mida me 1998. aastal piltidega mõtlesime, mitte seda, mida me 1998. aastal tegime sellega, mida me nüüd kutsume piltidena.

Ärge unustage domeeninime

Pidage meeles, et see kehtib mitte ainult URI-s oleva tee, vaid ka serveri nime kohta. Kui teil on erinevate asjade jaoks eraldi serverid, pidage meeles, et seda jaotust on võimatu muuta ilma paljusid-palju linke hävitamata. Mõned klassikalised vead "vaadake täna kasutatavat tarkvara" on domeeninimed "cgi.pathfinder.com", "secure", "lists.w3.org". Need on loodud serveri haldamise hõlbustamiseks. Olenemata sellest, kas domeen esindab teie ettevõtte osakonda, dokumendi olekut, juurdepääsutaset või turbetaset, olge väga-väga ettevaatlik, enne kui kasutate mitme dokumenditüübi jaoks rohkem kui ühte domeeninime. Pidage meeles, et saate ümbersuunamise ja puhverserveri abil peita mitu veebiserverit ühes nähtavas veebiserveris.

Oh, ja mõelge ka oma domeeninimele. Te ei soovi, et pärast tootesarja muutmist ja seebi valmistamise lõpetamist teile viidataks kui soap.com (Vabandan kõigile, kellele soap.com hetkel kuulub).

Järeldus

URI säilitamine 2, 20, 200 või isegi 2000 aastat pole ilmselgelt nii lihtne, kui tundub. Kuid kõikjal Internetis teevad veebihaldurid otsuseid, mis muudavad selle ülesande nende jaoks tulevikus tõeliselt keeruliseks. Tihti on põhjuseks see, et nad kasutavad tööriistu, mille ülesanne on esitleda ainult hetkel parimat saiti – ja keegi pole hinnanud, mis saab linkidest, kui kõik muutub. Siin on aga mõte selles, et paljud, paljud asjad võivad muutuda ning teie URI-d võivad ja peaksid jääma samaks. See on võimalik ainult siis, kui mõtlete, kuidas neid luua.

Vaata ka:

• Jakob Nielseni tiraad samal teemal

Lisandused

Kuidas eemaldada faililaiendeid...

... praeguse failipõhise veebiserveri URI-st?

Kui kasutate näiteks Apache'i, saate selle konfigureerida sisu läbirääkimisteks. Salvestage faililaiend (nt .png) faili (nt. mydog.png), kuid saate linkida veebiressursile ka ilma selleta. Seejärel kontrollib Apache kataloogist kõiki selle nime ja laiendiga faile ning saab valida komplektist parima (nt GIF ja PNG). Ja pole vaja paigutada eri tüüpi faile erinevatesse kataloogidesse, tegelikult sisu sobitamine ei toimi, kui teete seda.

• Seadistage oma server sisu läbirääkimisteks
• Linkige alati laiendita URI-dele

Laiendustega lingid töötavad endiselt, kuid ei lase teie serveril valida parimat praegu ja tulevikus saadaolevat vormingut.

(Tegelikult, mydog, mydog.png и mydog.gif — kehtivad veebiressursid, mydog on universaalne sisutüüpi ressurss ja mydog.png и mydog.gif — konkreetse sisutüübi ressursid).

Muidugi, kui kirjutate oma veebiserverit, on hea mõte kasutada andmebaasi, et siduda püsivad identifikaatorid nende praegusel kujul, kuigi olge ettevaatlik andmebaaside piiramatu kasvu eest.

The Board of Shame – 1. lugu: Kanal 7

1999. aastal jälgisin lehel lume tõttu koolide sulgemisi http://www.whdh.com/stormforce/closings.shtml. Ärge oodake, kuni teave teleriekraani allossa ilmub! Linkisin sellele oma kodulehelt. Saabub esimene suur lumetorm 2000 ja uurin lehte. Seal on kirjas:,

- Alates.
Hetkel pole midagi suletud. Ilmahoiatuste korral palun tagasi tulla.

Nii tugev torm ei saa olla. Naljakas, et kuupäev on puudu. Aga kui lähete saidi avalehele, on seal suur nupp "Suletud koolid", mis viib lehele http://www.whdh.com/stormforce/ pika nimekirjaga suletud koolidest.

Võib-olla muutsid nad loendi hankimise süsteemi, kuid nad ei pidanud URI-d muutma.

Häbilaud – 2. lugu: Microsoft Netmeeting

Seoses Interneti-sõltuvuse suurenemisega tekkis kaval idee, et rakendustesse saaks manustada linke tootja veebisaidile. Seda on palju kasutatud ja kuritarvitatud, kuid te ei saa URL-i muuta. Just eelmisel päeval proovisin linki Microsoft Netmeeting 2/something kliendilt Help/Microsoft on the Web/Free stuff menüüs ja sain tõrketeate 404 – serverilt vastust ei leitud. Võib-olla on see juba parandatud...

© 1998 Tim BL

Ajalooline märkus: 20. sajandi lõpus, kui see kirjutati, oli "lahe" heakskiidu epiteet, eriti noorte seas, mis viitas moekusele, kvaliteedile või sobivusele. Kiirustades valiti URI tee sageli pigem "jaheduse" kui kasulikkuse või vastupidavuse pärast. See postitus on katse suunata energia laheduse otsimise taga.

Allikas: www.habr.com