Avtor: Sir Tim Berners-Lee, izumitelj URI-jev, URL-jev, HTTP, HTML in svetovnega spleta ter trenutni vodja W3C. Članek napisan leta 1998

Kateri URI velja za "kul"?
Takšna, ki se ne spreminja.
Kako se spreminjajo URI-ji?
URI-ji se ne spreminjajo: ljudje jih spreminjajo.

V teoriji ni razloga, da bi ljudje spreminjali URI (ali prenehali spremljati dokumente), v praksi pa jih je na milijone.

V teoriji je nominalni lastnik imenskega prostora domene dejansko lastnik imenskega prostora domene in s tem vseh URI-jev v njem. Lastniku domene razen plačilne nesposobnosti nič ne preprečuje, da ime obdrži. V teoriji je prostor URI pod imenom vaše domene v celoti pod vašim nadzorom, tako da ga lahko naredite tako stabilnega, kot želite. Skoraj edini dober razlog, da dokument izgine iz interneta, je, da je podjetje, ki je imelo ime domene, prenehalo poslovati ali si ne more več privoščiti, da bi strežnik deloval. Zakaj je potem na svetu toliko manjkajočih členov? Nekaj od tega je preprosto pomanjkanje premišljenosti. Tukaj je nekaj razlogov, ki jih lahko slišite:

Pravkar smo reorganizirali stran, da bi jo izboljšali.

Ali res mislite, da stari URI-ji ne morejo več delovati? Če je tako, potem ste jih izbrali zelo slabo. Razmislite o tem, da bi obdržali nove za naslednjo prenovo.

Imamo toliko stvari, da ne moremo spremljati, kaj je zastarelo, kaj je zaupno in kaj je še vedno pomembno, zato se nam je zdelo najbolje, da vse preprosto izklopimo.

Lahko samo sočustvujem. W3C je šel skozi obdobje, ko smo morali skrbno pregledati arhivsko gradivo glede zaupnosti, preden smo ga objavili. Odločitev je treba premisliti vnaprej – poskrbite, da boste ob vsakem dokumentu zabeležili sprejemljivo branost, datum nastanka in v idealnem primeru datum poteka. Shranite te metapodatke.

No, ugotovili smo, da moramo premakniti datoteke ...

To je eden najbolj patetičnih izgovorov. Mnogi ljudje ne vedo, da vam spletni strežniki omogočajo nadzor razmerja med URI-jem predmeta in njegovo dejansko lokacijo v datotečnem sistemu. Zamislite si prostor URI kot abstrakten prostor, popolnoma organiziran. Nato naredite preslikavo v katero koli realnost, ki jo dejansko uporabljate za uresničitev. Nato to sporočite spletnemu strežniku. Lahko celo napišete svoj delček strežnika, da ga dobite pravilno.

John ne vzdržuje več te datoteke, zdaj jo Jane.

Je bilo Johnovo ime v URI? Ne, je bila datoteka le v njegovem imeniku? No, v redu.

Prej smo za to uporabljali skript CGI, zdaj pa uporabljamo binarni program.

Obstaja nora ideja, da bi se strani, ustvarjene s skripti, nahajale v območju "cgibin" ali "cgi". To razkrije mehaniko, kako zaženete svoj spletni strežnik. Spremenite mehanizem (tudi med shranjevanjem vsebine) in ups – vsi vaši URI-ji se spremenijo.

Vzemimo za primer Nacionalno znanstveno fundacijo (NSF):

Spletni dokumenti NSF

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

Prva stran, na kateri začnete pregledovati dokumente, čez nekaj let očitno ne bo več enaka. cgi-bin, oldbrowse и pl - vse to oddaja delčke informacij o tem, kako-to-delamo-zdaj. Če stran uporabite za iskanje dokumenta, je prvi rezultat, ki ga dobite, enako slab:

Poročilo delovne skupine za kriptologijo in teorijo kodiranja

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

za indeksno stran dokumenta, čeprav je sam dokument html videti veliko bolje:

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

Tu bo glava pubs/1998 kateri koli prihodnji arhivski službi dala dober namig, da velja stara shema klasifikacije dokumentov iz leta 1998. Čeprav so lahko številke dokumentov leta 2098 videti drugačne, si predstavljam, da bi bil ta URI še vedno veljaven in ne bi motil NSF ali katere koli druge organizacije, ki bi vzdrževala arhiv.

Nisem mislil, da morajo biti URL-ji trajni - obstajali so URN-ji.

To je verjetno eden najhujših stranskih učinkov razprave o URN. Nekateri ljudje mislijo, da bodo morda zaradi raziskav trajnejšega imenskega prostora neprevidni glede visečih povezav, ker bodo "URN-ji vse to popravili." Če ste eden od teh ljudi, potem naj vas razočaram.

Večina shem URN, ki sem jih videl, je videti kot identifikator organa, ki mu sledi bodisi datum in niz, ki ga izberete, ali samo niz, ki ga izberete. To je zelo podobno HTTP URI. Z drugimi besedami, če menite, da bo vaša organizacija sposobna ustvariti dolgožive URN-je, potem to dokažite zdaj in jih uporabite za svoje HTTP URI-je. V samem HTTP ni ničesar, zaradi česar je vaš URI nestabilen. Samo vaša organizacija. Ustvarite zbirko podatkov, ki preslika URN dokumenta v trenutno ime datoteke, in pustite, da jo spletni strežnik uporabi za dejansko pridobivanje datotek.

Če ste dosegli to točko, če nimate časa, denarja in povezav za razvoj neke programske opreme, lahko navedete naslednji izgovor:

Želeli smo, a preprosto nimamo pravega orodja.

Ampak s tem lahko sočustvuješ. Se popolnoma strinjam. Kar morate storiti, je prisiliti spletni strežnik, da takoj razčleni trajni URI in vrne datoteko, kjer koli je trenutno shranjena v vašem trenutnem norem datotečnem sistemu. Vse URI-je želite shraniti v datoteko kot preverjanje in ohraniti bazo podatkov vedno posodobljeno. Ohraniti želite razmerje med različnimi različicami in prevodi istega dokumenta ter ohraniti neodvisen zapis kontrolne vsote, da zagotovite, da datoteka ni poškodovana zaradi nenamerne napake. In spletni strežniki s temi funkcijami preprosto niso pripravljeni. Ko želite ustvariti nov dokument, vas urejevalnik prosi, da določite URI.

V prostoru URI morate imeti možnost spremeniti lastništvo, dostop do dokumenta, varnost na ravni arhiva itd., ne da bi spremenili URI.

Vse je hudo. Toda situacijo bomo popravili. Pri W3C uporabljamo funkcionalnost Jigedit (strežnik za urejanje sestavljanke), ki sledi različicam, in eksperimentiramo s skripti za ustvarjanje dokumentov. Če razvijate orodja, strežnike in odjemalce, bodite pozorni na to težavo!

Ta izgovor velja tudi za številne strani W3C, vključno s tole: torej delaj, kot rečem, ne tako, kot jaz.

Zakaj bi me moralo skrbeti?

Ko spremenite URI na vašem strežniku, ne morete nikoli popolnoma povedati, kdo bo imel povezave do starega URI-ja. To so lahko povezave z običajnih spletnih strani. Dodajte svojo stran med zaznamke. URI je bil morda načrkan na robu pisma prijatelju.

Ko nekdo sledi povezavi in ta ne deluje, običajno izgubi zaupanje v lastnika strežnika. Prav tako je razočaran, tako čustveno kot fizično, ker ne more doseči svojega cilja.

Veliko ljudi se ves čas pritožuje nad pokvarjenimi povezavami in upam, da je škoda očitna. Upam, da je očitna tudi škoda ugleda vzdrževalca strežnika, kjer je dokument izginil.

Torej, kaj naj storim? Oblikovanje URI

Spletni skrbnik je odgovoren za dodelitev URI-jev, ki jih je mogoče uporabiti v 2 letih, v 20 letih, v 200 letih. To zahteva premišljenost, organiziranost in odločnost.

URI-ji se spremenijo, če se spremeni katera koli informacija v njih. Zelo pomembno je, kako jih oblikujete. (Kaj, oblikovanje URI? Ali moram oblikovati URI? Da, o tem bi morali razmisliti). Oblikovanje v bistvu pomeni izpuščanje kakršnih koli informacij v URI.

Datum, ko je bil dokument ustvarjen – datum, ko je bil izdan URI – je nekaj, kar se ne bo nikoli spremenilo. Zelo uporaben je za ločevanje poizvedb, ki uporabljajo novi sistem, od tistih, ki uporabljajo stari sistem. To je dobro mesto za začetek z URI. Če je dokument datiran, tudi če bo dokument pomemben v prihodnosti, potem je to dober začetek.

Edina izjema je stran, ki je namerno "najnovejša" različica, na primer za celotno organizacijo ali njen velik del.

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

To je najnovejša kolumna Money Daily v reviji Money. Glavni razlog, da v tem URI-ju ni potrebe po datumu, je, da ni razloga za shranjevanje URI-ja, ki bo preživel dnevnik. Koncept Money Daily bo izginil, ko bo izginil Money. Če se želite povezati z vsebino, jo postavite ločeno v arhivu:

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

(Videti je dobro. Predvideva, da bo "denar" pomenil isto stvar v celotnem življenju pathfinder.com. Obstaja dvojnik "98" in nepotreben ".html", drugače pa je videti kot močan URI.

Kaj pustiti ob strani

Vse! Poleg datuma ustvarjanja vnos kakršnih koli informacij v URI na tak ali drugačen način zahteva težave.

Ime avtorja. Avtorstvo se lahko spremeni, ko bodo na voljo nove različice. Ljudje zapuščajo organizacije in predajajo stvari drugim.
Stvar. Je zelo težko. Na začetku je vedno videti dobro, a se presenetljivo hitro spremeni. O tem bom več govoril spodaj.
Status. Imeniki, kot so "staro", "osnutek" in tako naprej, da ne omenjamo "najnovejših" in "kul", se pojavljajo v vseh datotečnih sistemih. Dokumenti spremenijo status – sicer ne bi imelo smisla ustvarjati osnutkov. Najnovejša različica dokumenta potrebuje trajni identifikator, ne glede na njegov status. Naj status ni v imenu.
Dostop. Pri W3C smo spletno mesto razdelili na razdelke za zaposlene, člane in javnost. To se sliši dobro, seveda pa se dokumenti začnejo kot skupinske ideje zaposlenih, o njih se razpravlja s člani in nato postanejo javni seznanjeni. Res bi bilo škoda, če bi vsakič, ko je dokument odprt za širšo razpravo, vse stare povezave do njega pretrgane! Zdaj preidemo na preprosto kodo datuma.
Končnica datoteke. Zelo pogost pojav. "cgi", celo ".html" se bo v prihodnosti spremenil. Morda čez 20 let ne boste uporabljali HTML-ja za to stran, vendar bi morale današnje povezave do nje še vedno delovati. Kanonične povezave na spletnem mestu W3C ne uporabljajo razširitve (kako se to dela).
Programski mehanizmi. V URI-ju poiščite "cgi", "exec" in druge izraze, ki kričijo "poglejte, katero programsko opremo uporabljamo." Si kdo želi vse življenje pisati skripte Perl CGI? ne? Nato odstranite končnico .pl. Preberite priročnik strežnika, kako to storiti.
Ime diska. pridi no Ampak to sem videl.

Najboljši primer z našega spletnega mesta je torej preprosto

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

... poročilo o zapisniku sestanka predsednikov W3C.

Teme in razvrstitev po temah

O tej nevarnosti bom podrobneje govoril, saj je ena tistih stvari, ki se jim je najtežje izogniti. Običajno se teme končajo v URI-jih, ko svoje dokumente kategorizirate glede na delo, ki ga opravljajo. Toda ta razčlenitev se bo sčasoma spremenila. Imena območij se bodo spremenila. Pri W3C smo želeli spremeniti MarkUP v Markup in nato v HTML, da odraža dejansko vsebino razdelka. Poleg tega pogosto obstaja ravno imenski prostor. Čez 100 let ste prepričani, da ne boste želeli ničesar ponovno uporabiti? V našem kratkem življenju smo na primer že želeli ponovno uporabiti »Zgodovino« in »Slogovne liste«.

To je vabljiv način organiziranja spletnega mesta – in resnično vabljiv način organiziranja česar koli, vključno s celotnim spletom. To je odlična srednjeročna rešitev, vendar ima dolgoročno resne pomanjkljivosti.

Del razloga se skriva v filozofiji pomena. Vsak izraz v jeziku je potencialna tarča za združevanje v skupine in vsaka oseba ima lahko drugačno predstavo o tem, kaj pomeni. Ker so odnosi med entitetami bolj podobni spletu kot drevesu, lahko tudi tisti, ki se strinjajo s spletom, izberejo drugačno predstavitev drevesa. To so moja (pogosto ponavljana) splošna opažanja o nevarnostih hierarhične klasifikacije kot splošne rešitve.

Pravzaprav, ko uporabite ime teme v URI-ju, se zavežete k nekakšni klasifikaciji. Morda boste v prihodnosti raje izbrali drugo možnost. URI bo nato dovzeten za kršitve.

Razlog za uporabo predmetnega področja kot dela URI-ja je, da je odgovornost za pododdelke prostora URI-ja običajno delegirana, nato pa potrebujete ime organizacijskega organa – oddelka, skupine ali karkoli – ki je odgovoren za ta podprostor. To je URI, ki se veže na organizacijsko strukturo. Običajno je varno le, če je nadaljnji (levi) URI zaščiten z datumom: 1998/pics lahko vašemu strežniku pomeni "kaj smo mislili leta 1998 s slikami" in ne "kaj smo leta 1998 naredili s tem, kar zdaj imenujemo slike."

Ne pozabite na ime domene

Ne pozabite, da to ne velja le za pot v URI-ju, ampak tudi za ime strežnika. Če imate ločene strežnike za različne stvari, ne pozabite, da bo te delitve nemogoče spremeniti, ne da bi uničili veliko, veliko povezav. Nekatere klasične napake "poglejte si programsko opremo, ki jo uporabljamo danes" so imena domen "cgi.pathfinder.com", "secure", "lists.w3.org". Zasnovani so tako, da olajšajo administracijo strežnika. Ne glede na to, ali domena predstavlja oddelek v vašem podjetju, status dokumenta, raven dostopa ali varnostno raven, bodite zelo, zelo previdni, preden uporabite več kot eno ime domene za več vrst dokumentov. Ne pozabite, da lahko skrijete več spletnih strežnikov znotraj enega vidnega spletnega strežnika s preusmeritvijo in proxyjem.

Oh, pomislite tudi na ime svoje domene. Nočete, da bi vas imenovali soap.com, potem ko spremenite linijo izdelkov in prenehate izdelovati mila (Oprostite tistemu, ki je trenutno lastnik soap.com).

Zaključek

Ohranjanje URI-ja za 2, 20, 200 ali celo 2000 let očitno ni tako enostavno, kot se zdi. Vendar pa spletni skrbniki po vsem internetu sprejemajo odločitve, ki jim to nalogo v prihodnosti resnično otežujejo. Pogosto je to zato, ker uporabljajo orodja, katerih naloga je predstaviti najboljšo stran le v tem trenutku – in nihče ni ocenil, kaj se bo zgodilo s povezavami, ko se vse spremeni. Vendar je tukaj bistvo, da se lahko veliko, veliko stvari spremeni, vaši URI-ji pa lahko in morajo ostati enaki. To je mogoče le, če pomislite, kako jih ustvarite.

Glejte tudi.:

Tirada Jakoba Nielsena na isto temo

Dodatki

Kako odstraniti končnice datotek ...

... iz URI-ja v trenutnem datotečnem spletnem strežniku?

Če na primer uporabljate Apache, ga lahko konfigurirate za pogajanja o vsebini. Shranite pripono datoteke (npr. .png) v datoteko (npr. moj pes.png), vendar se lahko povežete s spletnim virom brez njega. Apache nato preveri imenik za vse datoteke s tem imenom in katero koli končnico ter lahko izbere najboljšo iz nabora (na primer GIF in PNG). In ni vam treba postavljati različnih vrst datotek v različne imenike, pravzaprav ujemanje vsebine ne bo delovalo, če to storite.

Nastavite svoj strežnik za pogajanja o vsebini
Vedno povežite z URI-ji brez razširitve

Povezave z razširitvami bodo še vedno delovale, vendar bodo preprečile, da bi vaš strežnik izbral najboljši format, ki je na voljo trenutno in v prihodnosti.

(Pravzaprav, mydog, mydog.png и mydog.gif — veljavni spletni viri, mydog je univerzalni vir vsebine in mydog.png и mydog.gif — viri določene vrste vsebine).

Seveda, če pišete lasten spletni strežnik, je dobra ideja, da uporabite bazo podatkov za vezavo trajnih identifikatorjev na njihovo trenutno obliko, čeprav bodite pozorni na neomejeno rast baze podatkov.

Tabla sramote - Zgodba 1: Kanal 7

Med letom 1999 sem na strani spremljal zaprtja šol zaradi snega http://www.whdh.com/stormforce/closings.shtml. Ne čakajte, da se informacije prikažejo na dnu TV zaslona! Nanj sem se povezal s svoje domače strani. Prišla je prva velika snežna nevihta leta 2000 in preverim stran. Tam piše:,

- Od.
Trenutno ni nič zaprto. Vrnite se v primeru vremenskih opozoril.

Ne more biti tako močna nevihta. Smešno je, da datuma manjka. Če pa greste na glavno stran spletnega mesta, bo velik gumb »Zaprte šole«, ki vodi do strani http://www.whdh.com/stormforce/ z dolgim seznamom zaprtih šol.

Mogoče so spremenili sistem za pridobivanje seznama - vendar jim ni bilo treba spremeniti URI-ja.

Tabla sramote - Zgodba 2: Microsoft Netmeeting

Z naraščajočo odvisnostjo od interneta se je porodila pametna ideja, da bi lahko v aplikacije vgradili povezave do spletne strani proizvajalca. To je bilo veliko uporabljeno in zlorabljeno, vendar URL-ja ne morete spremeniti. Ravno pred dnevi sem preizkusil povezavo iz odjemalca Microsoft Netmeeting 2/something v Help/Microsoft na meniju Web/Free stuff in prejel napako 404 - ni bilo mogoče najti odgovora strežnika. Mogoče je že popravljeno...

Zgodovinska opomba: V poznem 20. stoletju, ko je bilo to napisano, je bil "kul" epitet odobravanja, zlasti med mladimi, ki je označeval modnost, kakovost ali primernost. V naglici je bila pot URI pogosto izbrana zaradi "hladnosti" in ne zaradi uporabnosti ali trajnosti. Ta objava je poskus preusmeritve energije za iskanjem kul.

Vir: www.habr.com

Cool URI-ji se ne spreminjajo