Aŭtoro: Sir Tim Berners-Lee, inventinto de URIoj, URLoj, HTTP, HTML kaj la Tutmonda Reto, kaj nuna estro de la W3C. Artikolo skribita en 1998

Kia URI estas konsiderata "malvarma"?
Unu kiu ne ŝanĝas.
Kiel URIoj estas ŝanĝitaj?
URIoj ne ŝanĝas: homoj ŝanĝas ilin.

En teorio, ekzistas neniu kialo por homoj ŝanĝi URIojn (aŭ ĉesi subtenajn dokumentojn), sed praktike estas milionoj da ili.

En teorio, la nominala posedanto de domajna nomspaco fakte posedas la domajnan nomspacon kaj tial ĉiujn URIojn ene de ĝi. Krom nepagivo, nenio malhelpas la posedanton de domajna nomo konservi la nomon. Kaj en teorio, la URI-spaco sub via domajna nomo estas tute sub via kontrolo, do vi povas fari ĝin tiel stabila kiel vi volas. Preskaŭ la sola bona kialo por ke dokumento malaperas de la interreto estas, ke la kompanio, kiu posedis la domajnan nomon, elfunkciis aŭ ne plu povas pagi plu funkcii la servilon. Kial do estas tiom da mankantaj ligiloj en la mondo? Iuj el ĉi tio estas simple manko de antaŭpenso. Jen kelkaj kialoj, kiujn vi povus aŭdi:

Ni ĵus reorganizis la retejon por plibonigi ĝin.

Ĉu vi vere pensas, ke la malnovaj URI-oj ne plu povas funkcii? Se jes, tiam vi elektis ilin tre malbone. Konsideru konservi la novajn por la sekva restrukturado.

Ni havas tiom da aĵoj ke ni ne povas konservi trakon de kio estas malaktuala, kio estas konfidenca, kaj kio estas ankoraŭ grava, do ni opiniis ke estas plej bone simple malŝalti ĉion.

Mi povas nur simpatii. W3C travivis periodon, kie ni devis zorge ekzameni arkivajn materialojn por konfidenco antaŭ publikigi ilin. La decido devus esti pripensita anticipe - certigu, ke kun ĉiu dokumento vi registras la akcepteblan legantaron, kredaton kaj, ideale, limdaton. Konservu ĉi tiujn metadatumojn.

Nu, ni malkovris, ke ni devas movi dosierojn...

Ĉi tio estas unu el la plej kompatindaj ekskuzoj. Multaj homoj ne scias, ke retserviloj permesas vin kontroli la rilaton inter la URI de objekto kaj ĝia reala loko en la dosiersistemo. Pensu pri la URI-spaco kiel abstrakta spaco, perfekte organizita. Tiam faru mapadon al kia ajn realeco, kiun vi efektive uzas por realigi ĝin. Poste raportu ĉi tion al la retservilo. Vi povas eĉ skribi vian propran servilan fragmenton por korekti ĝin.

John ne plu konservas ĉi tiun dosieron, Jane nun faras.

Ĉu la nomo de Johano estis en la URI? Ne, ĉu la dosiero estis nur en lia dosierujo? Nu, bone.

Antaŭe ni uzis CGI-skripton por tio, sed nun ni uzas binaran programon.

Estas freneza ideo, ke paĝoj kreitaj per skriptoj devus troviĝi en la areo "cgibin" aŭ "cgi". Ĉi tio elmontras la mekanikon de kiel vi kuras vian retservilon. Vi ŝanĝas la mekanismon (eĉ dum konservado de enhavo), kaj ve - ĉiuj viaj URIoj ŝanĝiĝas.

Prenu la National Science Foundation (NSF) ekzemple:

Retaj Dokumentoj de NSF

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

La unua paĝo por komenci vidi dokumentojn klare ne restos la sama post kelkaj jaroj. cgi-bin, oldbrowse и pl - ĉio ĉi donas pecetojn da informoj pri kiel-ni-faru-tion-nun. Se vi uzas la paĝon por serĉi dokumenton, la unua rezulto, kiun vi ricevas, estas same malbona:

Raporto de la Laborgrupo pri Kriptologio kaj Kodiga Teorio

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

por la dokumentindeksa paĝo, kvankam la html-dokumento mem aspektas multe pli bone:

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

Ĉi tie la kaplinio pubs/1998 donos al ajna estonta arkiva servo bonan indicon, ke la malnova 1998-dokumenta klasifikskemo validas. Kvankam la dokumentnombroj povas aspekti malsame en 2098, mi imagus, ke ĉi tiu URI ankoraŭ validus kaj ne malhelpus NSF aŭ ajnan alian organizon, kiu konservus la arkivon.

Mi ne pensis, ke URLoj devas esti persistaj - estis URN-oj.

Ĉi tio verŝajne estas unu el la plej malbonaj kromefikoj de la URN-debato. Iuj homoj opinias, ke pro la esploro pri pli konstanta nomspaco, ili eble estos senzorgaj pri pendantaj ligiloj ĉar "URNoj riparos ĉion tion." Se vi estas unu el ĉi tiuj homoj, tiam lasu min seniluziigi vin.

Plej multaj URN-skemoj, kiujn mi vidis, aspektas kiel aŭtoritata identigilo sekvita de aŭ dato kaj ĉeno, kiun vi elektas, aŭ nur ĉeno, kiun vi elektas. Ĉi tio tre similas al HTTP-URI. Alivorte, se vi pensas, ke via organizo povos krei longvivajn URN-ojn, do pruvu ĝin nun uzante ilin por viaj HTTP-URI-oj. Estas nenio en HTTP mem, kio malstabiligas vian URI. Nur via organizo. Kreu datumbazon, kiu mapas la dokumenton URN al la nuna dosiernomo, kaj lasu la retservilon uzi ĝin por reale preni la dosierojn.

Se vi atingis ĉi tiun punkton, se vi ne havas la tempon, monon kaj konektojn por disvolvi iun programaron, tiam vi povas deklari la jenan senkulpigon:

Ni volis, sed ni simple ne havas la ĝustajn ilojn.

Sed vi povas simpatii kun ĉi tio. Mi tute konsentas. Kion vi devas fari estas devigi la retservilon tuj analizi la konstantan URI kaj resendi la dosieron kien ajn ĝi estas nuntempe konservita en via nuna freneza dosiersistemo. Vi volas konservi ĉiujn URIojn en dosiero kiel kontrolo kaj konservi la datumbazon ĝisdatigita ĉiam. Vi volas konservi la rilaton inter malsamaj versioj kaj tradukoj de la sama dokumento, kaj ankaŭ konservi sendependan kontrolsuman rekordon por certigi, ke la dosiero ne estas koruptita de hazarda eraro. Kaj retserviloj simple ne eliras el la skatolo kun ĉi tiuj funkcioj. Kiam vi volas krei novan dokumenton, via redaktisto petas vin specifi URI.

Vi devas povi ŝanĝi proprieton, dokumentan aliron, arkivnivelan sekurecon ktp. en la URI-spaco sen ŝanĝi la URI.

Estas domaĝe. Sed ni korektos la situacion. Ĉe W3C, ni uzas la funkcion Jigedit (Jigsaw-redakta servilo), kiu spuras versiojn, kaj ni eksperimentas kun dokument-generadaj skriptoj. Se vi disvolvas ilojn, servilojn kaj klientojn, atentu ĉi tiun problemon!

Ĉi tiu senkulpigo validas ankaŭ por multaj W3C-paĝoj, inkluzive de ĉi tiu: do faru kiel mi diras, ne kiel mi faras.

Kial mi zorgu?

Kiam vi ŝanĝas la URI en via servilo, vi neniam povas tute diri, kiu havos ligilojn al la malnova URI. Ĉi tiuj povas esti ligiloj de regulaj retpaĝoj. Legomarku vian paĝon. La URI eble estis skribaĉita en la marĝenoj de letero al amiko.

Kiam iu sekvas ligilon kaj ĝi estas rompita, ili kutime perdas fidon al la servilo posedanto. Li ankaŭ estas frustrita, kaj emocie kaj fizike, pro ne povi atingi sian celon.

Multaj homoj plendas pri rompitaj ligiloj la tutan tempon, kaj mi esperas, ke la damaĝo estas evidenta. Mi esperas, ke la reputacia damaĝo al la prizorganto de la servilo, kie la dokumento malaperis, estas ankaŭ evidenta.

Kion do mi faru? URI-dezajno

Estas la respondeco de la retestro asigni URI-ojn uzeblajn en 2 jaroj, en 20 jaroj, en 200 jaroj. Ĉi tio postulas pripensemon, organizon kaj persistemon.

URIoj ŝanĝiĝas se iu ajn informo en ili ŝanĝiĝas. Kiel vi desegnas ilin estas tre grava. (Kio, URI-dezajno? Ĉu mi bezonas desegni la URI? Jes, vi devus pensi pri tio). Dezajno esence signifas ellasi ajnan informon en la URI.

La dato, kiam la dokumento estis kreita - la dato, kiam la URI estis eldonita - estas io, kio neniam ŝanĝiĝos. Ĝi estas tre utila por apartigi demandojn, kiuj uzas la novan sistemon, de tiuj, kiuj uzas la malnovan sistemon. Ĉi tio estas bona loko por komenci kun URI. Se dokumento estas datita, eĉ se la dokumento estos grava en la estonteco, tiam ĉi tio estas bona komenco.

La sola escepto estas paĝo, kiu estas intence la "lasta" versio, ekzemple por la tuta organizo aŭ granda parto de ĝi.

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

Ĉi tiu estas la plej nova rubriko Money Daily en la revuo Money. La ĉefa kialo, ke ne necesas dato en ĉi tiu URI, estas ke ne ekzistas kialo por stoki la URI, kiu postvivos la protokolon. La koncepto de Money Daily malaperos kiam Money malaperos. Se vi volas ligi al enhavo, vi ligu al ĝi aparte en la arkivoj:

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

(Aspektas bone. Supozas ke "mono" signifos la samon dum la tuta vivo de pathfinder.com. Estas duplikato "98" kaj nenecesa ".html", sed alie aspektas kiel forta URI.

Kion lasi flanken

Ĉiuj! Krom la kredato, meti ajnan informon en la URI estas peti problemon unu aŭ alia.

Nomo de aŭtoro. Aŭtoreco povas ŝanĝiĝi kiam novaj versioj iĝas disponeblaj. Homoj forlasas organizojn kaj transdonas aferojn al aliaj.
Subjekto. Estas tre malfacila. Ĝi ĉiam aspektas bone komence, sed ŝanĝiĝas surprize rapide. Mi parolos pli pri tio ĉi sube.
Statuso. Dosierujoj kiel "malnova", "malneto" kaj tiel plu, sen mencii "lasta" kaj "kool", aperas en ĉiuj dosiersistemoj. Dokumentoj ŝanĝas statuson - alie ne havus signifon krei skizojn. La plej nova versio de dokumento bezonas konstantan identigilon, sendepende de ĝia stato. Konservu la statuson ekster la nomo.
Aliro. Ĉe W3C, ni dividis la retejon en sekciojn por dungitoj, membroj kaj publiko. Ĉi tio sonas bone, sed kompreneble dokumentoj komenciĝas kiel teamideoj de kunlaborantaro, estas diskutitaj kun membroj, kaj poste fariĝas publika scio. Vere estus domaĝe, se ĉiufoje kiam dokumento estas malfermita por pli vasta diskuto, ĉiuj malnovaj ligiloj al ĝi estas rompitaj! Nun ni transiru al simpla dato-kodo.
Dosiera etendo. Tre ofta fenomeno. "cgi", eĉ ".html" ŝanĝiĝos estonte. Vi eble ne uzos HTML-on por ĉi tiu paĝo en 20 jaroj, sed la hodiaŭaj ligiloj al ĝi ankoraŭ devus funkcii. Kanonikaj ligiloj en la retejo de W3C ne uzas la etendon (kiel ĝi estas farita).
Programaj mekanismoj. En la URI, serĉu "cgi", "exec" kaj aliajn terminojn, kiuj krias "rigardu kian programaron ni uzas." Ĉu iu volas pasigi sian tutan vivon skribante Perl CGI-skriptojn? Ne? Tiam forigu la etendon .pl. Legu la manlibron pri servilo pri kiel fari tion.
Diskonomo. Venu! Sed mi vidis ĉi tion.

Do la plej bona ekzemplo de nia retejo estas simple

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

... raportu pri la protokolo de la kunveno de la Prezidantoj de W3C.

Temoj kaj klasifiko laŭ temo

Mi eniros pli detale pri ĉi tiu danĝero, ĉar ĝi estas unu el tiuj aferoj, kiuj estas plej malfacile eviti. Tipe, temoj finiĝas en URIoj kiam vi klasifikas viajn dokumentojn laŭ la laboro, kiun ili faras. Sed ĉi tiu rompo ŝanĝiĝos kun la tempo. La nomoj de la areoj ŝanĝiĝos. Ĉe W3C ni volis ŝanĝi MarkUP al Markup kaj poste al HTML por reflekti la realan enhavon de la sekcio. Krome, estas ofte plata nomspaco. Post 100 jaroj, ĉu vi certas, ke vi volas nenion reuzi? En nia mallonga vivo ni jam volis reuzi ekzemple "Historio" kaj "Stilfolioj".

Estas tenta maniero organizi retejon—kaj vere tenta maniero organizi ion ajn, inkluzive de la tuta TTT-ejo. Ĉi tio estas bonega meztempa solvo sed havas gravajn mankojn longtempe.

Parto de la kialo kuŝas en la filozofio de signifo. Ĉiu termino en lingvo estas ebla celo por amasiĝo, kaj ĉiu persono povas havi malsaman ideon pri tio, kion ĝi signifas. Ĉar rilatoj inter entoj pli similas al reto ol al arbo, eĉ tiuj, kiuj konsentas kun la reto, povas elekti malsaman reprezentadon de la arbo. Ĉi tiuj estas miaj (ofte ripetataj) ĝeneralaj observoj pri la danĝeroj de hierarkia klasifiko kiel ĝenerala solvo.

Fakte, kiam vi uzas temnomon en URI, vi kompromitas vin al ia klasifiko. Eble estonte vi preferos alian eblon. La URI tiam estos susceptible al malobservo.

La kialo por uzi temon kiel parton de URI estas, ke respondeco pri subsekcioj de la URI-spaco estas kutime delegita, kaj tiam vi bezonas la nomon de la organiza korpo - fako, grupo aŭ kio ajn - kiu respondecas pri tiu subspaco. Ĉi tio estas URI liganta al organiza strukturo. Ĝi estas kutime nur sekura se la plia (maldekstre) URI estas protektita per dato: 1998/fotoj povus signifi por via servilo "kion ni volis diri en 1998 per fotoj" prefere ol "kio en 1998 ni faris per tio, kion ni nun nomas bildoj."

Ne forgesu la domajnan nomon

Memoru, ke tio validas ne nur por la vojo en la URI, sed ankaŭ por la servila nomo. Se vi havas apartajn servilojn por malsamaj aferoj, memoru, ke ĉi tiu divido estos neeble ŝanĝi sen detrui multajn, multajn ligilojn. Iuj klasikaj eraroj "rigardu la programaron, kiun ni uzas hodiaŭ", estas domajnaj nomoj "cgi.pathfinder.com", "secure", "lists.w3.org". Ili estas desegnitaj por faciligi administradon de la servilo. Sendepende de ĉu domajno reprezentas dividadon en via kompanio, dokumentstatuson, alirnivelon aŭ sekurecan nivelon, estu tre, tre singarda antaŭ ol uzi pli ol unu domajnan nomon por pluraj dokumentspecoj. Memoru, ke vi povas kaŝi plurajn retservilojn ene de unu videbla retservilo uzante alidirektilon kaj prokuradon.

Ho, kaj ankaŭ pensu pri via domajna nomo. Vi ne volas esti referita kiel soap.com post kiam vi ŝanĝos produktliniojn kaj ĉesos fari sapon (Pardonu al kiu ajn posedas soap.com nuntempe).

konkludo

Konservi URI dum 2, 20, 200, aŭ eĉ 2000 jaroj evidente ne estas tiel facila kiel ĝi ŝajnas. Tamen, ĉie en la Interreto, retejestroj faras decidojn, kiuj faras ĉi tiun taskon vere malfacila por si en la estonteco. Ofte tio estas ĉar ili uzas ilojn, kies tasko estas prezenti la plej bonan retejon nur momente - kaj neniu taksis kio okazos al la ligiloj kiam ĉio ŝanĝiĝos. Tamen, la punkto ĉi tie estas, ke multaj, multaj aferoj povas ŝanĝiĝi, kaj viaj URIoj povas kaj devas resti la samaj. Ĉi tio eblas nur kiam vi pensas pri kiel vi kreas ilin.

Vidu ankaŭ:

La tirado de Jakob Nielsen pri la sama temo

Aldonoj

Kiel forigi dosierajn etendojn...

...de URI en la nuna dosier-bazita retservilo?

Se vi uzas Apache, ekzemple, vi povas agordi ĝin por negoci enhavon. Konservu la dosier-etendaĵon (ekz. .png) al dosiero (ekz. miahundo.png), sed vi povas ligi al interreta rimedo sen ĝi. Apache tiam kontrolas la dosierujon por ĉiuj dosieroj kun tiu nomo kaj ajna etendaĵo, kaj povas elekti la plej bonan el la aro (ekzemple, GIF kaj PNG). Kaj ne necesas meti malsamajn specojn de dosieroj en malsamaj dosierujoj, fakte kongruo de enhavo ne funkcios se vi faros tion.

Agordu vian servilon por negoci enhavon
Ĉiam ligu al URI-oj sen etendo

Ligiloj kun etendoj daŭre funkcios, sed malhelpos vian servilon elekti la plej bonan formaton disponeblan nuntempe kaj estonte.

(Fakte, mydog, mydog.png и mydog.gif - validaj interretaj rimedoj, mydog estas universala enhavtipa rimedo, kaj mydog.png и mydog.gif — rimedoj de specifa enhavotipo).

Kompreneble, se vi skribas vian propran retservilon, estas bona ideo uzi datumbazon por ligi konstantajn identigilojn al ilia nuna formo, kvankam atentu kontraŭ senlima datumbaza kresko.

La Estraro de Honto - Rakonto 1: Kanalo 7

Dum 1999, mi spuris lernejfermojn pro neĝo sur paĝo http://www.whdh.com/stormforce/closings.shtml. Ne atendu, ke la informoj aperos malsupre de la televida ekrano! Mi ligis al ĝi de mia ĉefpaĝo. La unua granda neĝoŝtormo de 2000 alvenas kaj mi kontrolas la paĝon. Tie estas skribite:,

- Ekde.
Nenio estas nuntempe fermita. Bonvolu reveni en kazo de veteravertoj.

Ne povas esti tiel forta ŝtormo. Estas amuze, ke la dato mankas. Sed se vi iras al la ĉefa paĝo de la retejo, estos granda butono "Fermitaj Lernejoj", kiu kondukas al la paĝo. http://www.whdh.com/stormforce/ kun longa listo de fermitaj lernejoj.

Eble ili ŝanĝis la sistemon por ricevi la liston - sed ili ne bezonis ŝanĝi la URI.

Estraro de Honto - Rakonto 2: Microsoft Netmeeting

Kun la kreskanta dependeco de la Interreto, venis saĝa ideo, ke ligiloj al la retejo de la fabrikanto povus esti enigitaj en aplikoj. Ĉi tio estis multe uzata kaj misuzita, sed vi ne povas ŝanĝi la URL. Ĝuste la alian tagon mi provis ligilon de la Microsoft Netmeeting 2/io kliento en la Helpo/Mikrosofto en la TTT/Senpaga aĵo-menuo kaj ricevis 404-eraron - neniu respondo de la servilo estis trovita. Eble ĝi jam estas riparita...

Historia noto: En la malfrua 20-a jarcento, kiam tio estis skribita, "malvarmeto" estis epiteto de aprobo, precipe inter junuloj, indikante modecon, kvaliton aŭ taŭgecon. Rapide, la URI-vojo ofte estis elektita por "malvarmeco" prefere ol utileco aŭ fortikeco. Ĉi tiu afiŝo estas provo redirekti la energion malantaŭ la serĉo de malvarmeta.

fonto: www.habr.com

Bonegaj URI-oj ne ŝanĝiĝas