Auteur: Sir Tim Berners-Lee, útfiner fan URI's, URL's, HTTP, HTML en it World Wide Web, en hjoeddeistige haad fan 'e W3C. Artikel skreaun yn 1998

Hokker URI wurdt beskôge as "cool"?
Ien dy't net feroaret.
Hoe wurde URI's feroare?
URI's feroarje net: minsken feroarje se.

Yn teory is d'r gjin reden foar minsken om URI's te feroarjen (of stopje mei stypjende dokuminten), mar yn 'e praktyk binne d'r miljoenen fan.

Yn teory is de nominale eigner fan in domeinnammeromte eins eigener fan de domeinnammeromte en dus alle URI's dêryn. Behalven insolvinsje hinderet neat de eigner fan in domeinnamme om de namme te behâlden. En yn teory is de URI-romte ûnder jo domeinnamme folslein ûnder jo kontrôle, dus jo kinne it sa stabyl meitsje as jo wolle. Sawat de ienige goede reden foar in dokumint om te ferdwinen fan it ynternet is dat it bedriuw dat de domeinnamme hie, út it bedriuw gien is of it net mear kin betelje om de tsjinner draaiend te hâlden. Wêrom binne d'r dan safolle ûntbrekkende keppelings yn 'e wrâld? Guon fan dit is gewoan in gebrek oan foargedachte. Hjir binne wat redenen dy't jo miskien hearre:

Wy hawwe de side krekt reorganisearre om it better te meitsjen.

Tinke jo echt dat de âlde URI's net mear kinne wurkje? As dat sa is, dan hawwe jo se tige min keazen. Tink derom om de nije te hâlden foar de folgjende werynrjochting.

Wy hawwe safolle guod dat wy net byhâlde kinne wat ferâldere is, wat fertroulik is en wat noch relevant is, dus we tochten it bêste om it gewoan út te setten.

Ik kin allinnich sympatisearje. W3C gie troch in perioade wêr't wy argyfmaterialen foarsichtich moasten siftje foar fertroulikens foardat se iepenbier makken. It beslút moat fan tefoaren betocht wurde - soargje derfoar dat jo by elk dokumint in akseptabel lêzerspublyk, oanmaakdatum en, ideaal, ferfaldatum opnimme. Bewarje dizze metadata.

No, wy ûntdutsen dat wy bestannen moatte ferpleatse ...

Dit is ien fan de meast patetyske ekskús. In protte minsken witte net dat webservers jo de relaasje kinne kontrolearje tusken de URI fan in objekt en de eigentlike lokaasje yn it bestânsysteem. Tink oan de URI-romte as in abstrakte romte, perfekt organisearre. Meitsje dan in mapping nei hokker realiteit jo eins brûke om it te realisearjen. Meld dit dan oan de webserver. Jo kinne sels jo eigen serverfragment skriuwe om it goed te krijen.

John hâldt dit bestân net mear by, Jane docht dat no.

Wie Johannes syn namme yn 'e URI? Nee, stie it bestân gewoan yn syn map? No, goed.

Earder brûkten wy hjir in CGI-skript foar, mar no brûke wy in binêre programma.

D'r is in gek idee dat siden makke troch skripts yn it "cgibin" of "cgi" gebiet moatte lizze. Dit bleatstelt de meganika fan hoe't jo jo webserver útfiere. Jo feroarje it meganisme (sels by it bewarjen fan ynhâld), en oeps - al jo URI's feroarje.

Nim de National Science Foundation (NSF) bygelyks:

NSF Online dokuminten

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

De earste side om dokuminten te besjen sil dúdlik net oer in pear jier itselde bliuwe. cgi-bin, oldbrowse и pl - dit alles jout stikjes ynformaasje oer hoe-wy-it-no-doe. As jo ​​de side brûke om nei in dokumint te sykjen, is it earste resultaat dat jo krije like min:

Ferslach fan 'e Wurkgroep oer Kryptology en Koadeteory

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

foar de dokumintyndeksside, hoewol it html-dokumint sels folle better sjocht:

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

Hjir sil de koptekst kroegen/1998 elke takomstige argyftsjinst in goede oanwizing jaan dat it âlde dokumintklassifikaasjeskema fan 1998 yn wurking is. Hoewol't de dokumint nûmers kinne sjen oars yn 2098, Ik soe yntinke dat dizze URI soe noch wêze jildich en soe net bemuoie mei NSF of in oare organisaasje dy't soe ûnderhâlde it argyf.

Ik tocht net dat URL's persistent moasten wêze - d'r wiene URN's.

Dit is wierskynlik ien fan 'e minste side-effekten fan it URN-debat. Guon minsken tinke dat se fanwegen it ûndersyk nei in mear permaninte nammeromte ûnferskillich wêze kinne oer bongeljende keppelings, om't "URN's dat alles sille reparearje." As jo ​​​​ien fan dizze minsken binne, lit my jo dan teloarstelle.

De measte URN-skema's dy't ik haw sjoen lykje op in autoriteitsidentifikaasje folge troch of in datum en in tekenrige dy't jo selektearje, of gewoan in tekenrige dy't jo selektearje. Dit is heul gelyk oan in HTTP URI. Mei oare wurden, as jo tinke dat jo organisaasje yn steat is om lange libbene URN's te meitsjen, bewize it dan no troch se te brûken foar jo HTTP URI's. D'r is neat yn HTTP sels dat jo URI ynstabyl makket. Allinnich jo organisaasje. Meitsje in databank dy't it dokumint URN yn kaart bringt nei de aktuele bestânsnamme, en lit de webserver it brûke om de bestannen feitlik op te heljen.

As jo ​​​​dit punt hawwe berikt, as jo net de tiid, jild en ferbiningen hawwe om wat software te ûntwikkeljen, dan kinne jo it folgjende ekskús oanjaan:

Wy woenen wol, mar wy hawwe gewoan net it goede ark.

Mar hjir kinne jo sympatisearje mei. Ik bin it hielendal mei iens. Wat jo moatte dwaan is de webserver twinge om de persistente URI direkt te parsearjen en it bestân werom te jaan wêr't it op it stuit is opslein op jo hjoeddeistige gekke bestânsysteem. Jo wolle alle URI's yn in bestân bewarje as kontrôle en de databank altyd by de tiid hâlde. Jo wolle de relaasje tusken ferskate ferzjes en oersettingen fan itselde dokumint behâlde, en ek in ûnôfhinklike kontrôlesumrecord hâlde om te soargjen dat it bestân net beskeadige wurdt troch in tafallige flater. En webservers komme gewoan net út 'e doaze mei dizze funksjes. As jo ​​in nij dokumint wolle oanmeitsje, freget jo bewurker jo om in URI op te jaan.

Jo moatte eigendom kinne feroarje, tagong ta dokuminten, befeiliging fan argyfnivo, ensfh. yn 'e URI-romte sûnder de URI te feroarjen.

It is al te min. Mar wy sille de situaasje korrigearje. By W3C brûke wy de funksjonaliteit Jigedit (Jigsaw editing server) dy't ferzjes folget, en wy eksperimintearje mei skripts foar generaasje fan dokuminten. As jo ​​​​ark, servers en kliïnten ûntwikkelje, jouwe dan omtinken oan dit probleem!

Dit ekskús jildt ek foar in protte W3C-siden, ynklusyf dizze: doch sa't ik sis, net sa't ik doch.

Wat nukt my dat?

As jo ​​​​de URI op jo tsjinner feroarje, kinne jo noait folslein fertelle wa't keppelings sil hawwe nei de âlde URI. Dit kinne keppelings wêze fan gewoane websiden. Blêdwizer jo side. De URI kin yn 'e marzjes fan in brief oan in freon skrast wurde.

As immen in keppeling folget en it is brutsen, ferlieze se gewoanlik it fertrouwen yn 'e servereigner. Hy is ek frustrearre, sawol emosjoneel as fysyk, troch it net te berikken fan syn doel.

In protte minsken kleie oer brutsen keppelings hieltyd, en ik hoopje dat de skea is fanselssprekkend. Ik hoopje dat de reputaasjeskea oan 'e ûnderhâlder fan' e server wêr't it dokumint ferdwûn is ek dúdlik is.

Dus wat moat ik dwaan? URI ûntwerp

It is de ferantwurdlikens fan 'e webmaster om URI's te allocearjen dy't yn 2 jier, yn 20 jier, yn 200 jier kinne wurde brûkt. Dit freget omtinkens, organisaasje en fêststelling.

URI's feroarje as ienige ynformaasje yn har feroaret. Hoe't jo se ûntwerpe is heul wichtich. (Wat, URI-ûntwerp? Moat ik de URI ûntwerpe? Ja, dêr moatte jo oer tinke). Untwerp betsjut yn prinsipe it ferlitten fan alle ynformaasje yn 'e URI.

De datum dat it dokumint is makke - de datum dat de URI is útjûn - is iets dat noait sil feroarje. It is heul nuttich foar it skieden fan fersiken dy't it nije systeem brûke fan dyjingen dy't it âlde systeem brûke. Dit is in goed plak om te begjinnen mei in URI. As in dokumint datearre is, sels as it dokumint yn 'e takomst relevant is, dan is dit in goed begjin.

De ienige útsûndering is in side dy't mei opsetsin de "lêste" ferzje is, bygelyks foar de hiele organisaasje of in grut part derfan.

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

Dit is de lêste Money Daily kolom yn Money magazine. De wichtichste reden dat d'r gjin ferlet is fan in datum yn dizze URI is dat d'r gjin reden is om de URI op te slaan dy't it log oerlibje sil. It konsept fan Money Daily sil ferdwine as Money ferdwynt. As jo ​​keppele wolle nei ynhâld, moatte jo der apart nei keppelje yn 'e argiven:

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

(Sjocht der goed út. Der wurdt fan útgien dat "jild" sil betsjutte itselde ding yn it hiele libben fan pathfinder.com. Der is in duplikaat "98" en in net nedich ".html", mar oars liket op in sterke URI.

Wat te ferlitten kant

Alle! Neist de skeppingsdatum freget it pleatsen fan ynformaasje yn 'e URI op ien of oare manier om problemen.

• Namme fan de auteur. Auteurskip kin feroarje as nije ferzjes beskikber komme. Minsken ferlitte organisaasjes en jouwe dingen troch oan oaren.
• Ûnderwerp. It is hiel dreech. It sjocht der earst altyd goed út, mar feroaret ferrassend fluch. Ik sil hjirûnder mear oer prate.
• Status. Directorys lykas "âld", "ûntwerp" ensafuorthinne, net te hawwen oer "lêste" en "cool", ferskine yn alle triemsystemen. Dokuminten feroarje status - oars soe it gjin punt hawwe om ûntwerpen te meitsjen. De lêste ferzje fan in dokumint hat in persistente identifier nedich, nettsjinsteande de status. Hâld de status út 'e namme.
• Tagong. By W3C hawwe wy de side ferdield yn seksjes foar personiel, leden en it publyk. Dit klinkt goed, mar fansels begjinne dokuminten as teamideeën fan meiwurkers, wurde besprutsen mei leden, en wurde dan iepenbiere kennis. It soe echt spitich wêze as eltse kear as in dokumint iepene wurdt foar bredere diskusje, alle âlde keppelings dernei ferbrutsen wurde! No geane wy ​​nei in ienfâldige datumkoade.
• Triem tafoeging. In hiel gewoan ferskynsel. "cgi", sels ".html" sil yn 'e takomst feroarje. Jo meie oer 20 jier gjin HTML brûke foar dizze side, mar de keplingen fan hjoed moatte noch wurkje. Kanonike keppelings op 'e W3C-side brûke de tafoeging net (hoe't it dien is).
• Software meganismen. Sjoch yn 'e URI nei "cgi", "exec" en oare termen dy't skrieme "sjoch nei hokker software wy brûke." Wolle immen har hiele libben besteegje oan it skriuwen fan Perl CGI-skripts? Nee? Fuortsmite dan de .pl tafoeging. Lês de tsjinner hantlieding oer hoe't jo dit dwaan.
• Skiif namme. Kom op! Mar ik haw dit sjoen.

Dat it bêste foarbyld fan ús side is gewoan

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

... rapportearje oer de notulen fan 'e W3C-foarsittersgearkomste.

Underwerpen en klassifikaasje troch ûnderwerp

Ik sil mear yngean oer dit gefaar, om't it ien fan 'e dingen is dy't it dreechst te foarkommen is. Typysk einigje ûnderwerpen yn URI's as jo jo dokuminten kategorisearje neffens it wurk dat se dogge. Mar dizze ferdieling sil feroarje oer de tiid. De nammen fan de gebieten sille feroarje. By W3C woene wy ​​MarkUP feroarje nei Markup en dan nei HTML om de eigentlike ynhâld fan 'e seksje te reflektearjen. Dêrneist is der faak in platte nammeromte. Binne jo oer 100 jier wis dat jo neat opnij brûke wolle? Yn ús koarte libben woene wy ​​bygelyks "History" en "Style Sheets" opnij brûke.

It is in ferleidende manier om in webside te organisearjen - en in wirklik ferliedlike manier om alles te organisearjen, ynklusyf it heule web. Dit is in geweldige oplossing op middellange termyn, mar hat op 'e lange termyn serieuze tekortkomingen.

In part fan 'e reden leit yn' e filosofy fan betsjutting. Elke term yn in taal is in potinsjele doel foar klustering, en elke persoan kin in oar idee hawwe fan wat it betsjut. Sûnt relaasjes tusken entiteiten binne mear as in web as in beam, sels dyjingen dy't it iens binne mei it web meie kieze in oare fertsjintwurdiging fan de beam. Dit binne myn (faak werhelle) algemiene observaasjes oer de gefaren fan hiërargyske klassifikaasje as in algemiene oplossing.

Yn feite, as jo in ûnderwerpnamme brûke yn in URI, sette jo jo yn op in soarte fan klassifikaasje. Miskien yn 'e takomst sille jo leaver in oare opsje. De URI sil dan gefoelich wêze foar oertreding.

De reden foar it brûken fan in fakgebiet as ûnderdiel fan in URI is dat ferantwurdlikens foar subseksjes fan 'e URI-romte meastentiids delegearre wurdt, en dan hawwe jo de namme nedich fan it organisatoarysk orgaan - ôfdieling, groep, of wat dan ek - dat ferantwurdlik is foar dy subromte. Dit is in URI binend oan in organisatoaryske struktuer. It is normaal allinich feilich as de fierdere (linker) URI wurdt beskerme troch in datum: 1998/pics kin betsjutte foar jo tsjinner "wat wy yn 1998 bedoelden mei foto's" ynstee fan "wat wy yn 1998 diene mei wat wy no foto's neame."

Ferjit de domeinnamme net

Tink derom dat dit net allinich jildt foar it paad yn 'e URI, mar ek foar de servernamme. As jo ​​​​ûnderskate servers hawwe foar ferskate dingen, tink dan dat dizze divyzje ûnmooglik wêze sil om te feroarjen sûnder in protte, in protte keppelings te ferneatigjen. Guon klassike "sjoch nei de software dy't wy hjoed brûke" flaters binne domeinnammen "cgi.pathfinder.com", "secure", "lists.w3.org". Se binne ûntworpen om serveradministraasje makliker te meitsjen. Nettsjinsteande oft in domein in divyzje yn jo bedriuw fertsjintwurdiget, in dokumintstatus, in tagongsnivo, of in feiligensnivo, wês heul, heul foarsichtich foardat jo mear as ien domeinnamme brûke foar meardere dokuminttypen. Unthâld dat jo meardere webservers kinne ferbergje binnen ien sichtbere webserver mei omlieding en proxying.

Oh, en tink ek oer jo domeinnamme. Jo wolle net oantsjut wurde as soap.com neidat jo produkt rigels feroarje en stopje mei it meitsjen fan sjippe (Sorry foar wa't soap.com hat op it stuit).

konklúzje

It behâld fan in URI foar 2, 20, 200, of sels 2000 jier is fansels net sa maklik as it liket. Oeral op it ynternet meitsje webmasters lykwols besluten dy't dizze taak yn 'e takomst echt lestich meitsje foar harsels. Faak is dit om't se ark brûke waans taak is om de bêste side allinich op it stuit te presintearjen - en gjinien hat beoardiele wat der sil barre mei de keppelings as alles feroaret. It punt hjir is lykwols dat in protte, in protte dingen kinne feroarje, en jo URI's kinne en moatte itselde bliuwe. Dit is allinich mooglik as jo tinke oer hoe't jo se meitsje.

Sjoch ek:

• Jakob Nielsen syn tirade oer itselde ûnderwerp

Oanfollingen

Hoe kinne jo triemtafoegings fuortsmite ...

...fan in URI yn 'e hjoeddeiske triem-basearre webtsjinner?

As jo ​​bygelyks Apache brûke, kinne jo it ynstelle om ynhâld te ûnderhanneljen. Bewarje de triem-útwreiding (bgl. .png) yn in bestân (bgl. mydog.png), mar jo kinne keppelje nei in webboarne sûnder dat. Apache kontrolearret dan de map foar alle bestannen mei dy namme en elke tafoeging, en kin de bêste kieze út 'e set (bygelyks GIF en PNG). En d'r is gjin ferlet om ferskate soarten bestannen yn ferskate mappen te pleatsen, feitlik sil oerienkomst fan ynhâld net wurkje as jo dat dogge.

• Stel jo tsjinner yn om ynhâld te ûnderhanneljen
• Altyd keppelje oan URI's sûnder útwreiding

Keppelings mei tafoegings sille noch wurkje, mar sille foarkomme dat jo tsjinner it bêste formaat dat op dit stuit en yn 'e takomst beskikber sil kieze.

(Yn feite, mydog, mydog.png и mydog.gif - jildige webboarnen, mydog is in universele ynhâld type boarne, en mydog.png и mydog.gif - boarnen fan in spesifyk ynhâldstype).

Fansels, as jo jo eigen webserver skriuwe, is it in goed idee om in databank te brûken om persistente identifiers te binen oan har hjoeddeistige foarm, hoewol pas op foar ûnbeheinde databankgroei.

The Board of Shame - Ferhaal 1: Kanaal 7

Tidens 1999 haw ik skoalsluitingen folge troch snie op side http://www.whdh.com/stormforce/closings.shtml. Wachtsje net oant de ynformaasje oan 'e ûnderkant fan it tv-skerm ferskynt! Ik keppele nei it fan myn thússide. De earste grutte sniestoarm fan 2000 komt en ik kontrolearje de side. Dêr stiet skreaun:,

- Lykas.
Der is op it stuit neat sletten. Graach werom yn gefal fan waar warskôgings.

Sa'n hurde stoarm kin it net wêze. It is grappich dat de datum mist. Mar as jo nei de haadside fan 'e side gean, sil d'r in grutte knop "Sluten skoallen" wêze, dy't liedt nei de side http://www.whdh.com/stormforce/ mei in lange list fan sluten skoallen.

Miskien hawwe se it systeem feroare om de list te krijen - mar se hoege de URI net te feroarjen.

Board of Shame - Ferhaal 2: Microsoft Netmeeting

Mei de tanimmende ôfhinklikens fan it ynternet kaam der in tûk idee dat keppelings nei de webside fan de fabrikant yn applikaasjes ynbêde koenen. Dit is in protte brûkt en misbrûkt, mar jo kinne de URL net feroarje. Krekt de oare deis besocht ik in kepling fan de Microsoft Netmeeting 2/something client yn it menu Help/Microsoft op it web/Free stuff en krige in 404 flater - gjin antwurd fan de tsjinner waard fûn. Miskien hawwe se it al reparearre...

© 1998 Tim BL

Histoaryske notysje: Yn 'e lette 20e ieu, doe't dit skreaun waard, wie "cool" in epithet fan goedkarring, foaral ûnder jonge minsken, wat oanjout fan modieuze, kwaliteit of passend. Yn 'e haast waard it URI-paad faaks keazen foar "coolness" ynstee fan nut of duorsumens. Dit berjocht is in besykjen om de enerzjy efter it sykjen nei koel troch te lieden.

Boarne: www.habr.com