Autori — sir Tim Berners-Lee, shpikues i URI, URL, HTTP, HTML dhe Web-it të Botës, drejtor aktual i W3C. Artikulli është shkruar në vitin 1998.

Cili URI mund të quhet "i cool"?
Ai që nuk ndryshon.
Si ndryshojnë URI-të?
URI-të nuk ndryshojnë: ato i ndryshojnë njerëzit.

Në teori, njerëzit nuk kanë asnjë arsye për të ndryshuar URI-të (ose për të ndalur mbështetje për dokumentet), por në praktikë janë miliona.

Teorikisht, pronari nominal i hapësirës së emrave të domain-it në të vërtetë zotëron hapësirën e emrave të domain-it dhe, për rrjedhojë, të gjitha URI-të që ndodhen brenda saj. Përveç falimentimit, asgjë nuk e pengon pronarin e emrit të domain-it ta mbajë këtë emër. Dhe teorikisht, hapësira e URI-s nën emrin tuaj të domain-it është plotësisht nën kontrollin tuaj, kështu që mund ta bëni sa më të qëndrueshëm që dëshironi. Në masën e madhe, arsyeja e vetme e vlefshme për zhdukjen e dokumenteve nga interneti është se kompania që e zotëronte emrin e domain-it ka dalë nga biznesi ose nuk mund të përballojë më mbajtjen e serverit. Atëherë pse në botë ka kaq shumë lidhje të humbura? Pjesërisht kjo është thjesht mungesë parapërgatitjeje. Ja disa arsye që mund të dëgjoni:

Ne sapo e riorganizuam faqen për ta bërë atë më të mirë.

A vërtet keni mendimin se URI-të e vjetra nuk mund të funksionojnë më? Nëse po, atëherë i keni zgjedhur ato shumë keq. Mendoni për mënyrën se si t'i ruani ato pas ridizajnimit të ardhshëm.

Kemi aq shumë material, sa që nuk mund të ndjekim se çfarë është e vjetruar, çfarë është konfidencial, dhe çfarë është ende aktuale, prandaj menduam se ishte më mirë ta çaktivizonim të gjithë këtë.

Mund të them vetëm se më vjen keq. W3C ka kaluar një periudhë kur na duhej të kalonim me kujdes materialet arkivore për të verifikuar konfidencialitetin para se t'i bënim ato publike. Zgjidhja duhet të menduar paraprakisht - sigurohuni që të regjistroni me çdo dokument grupin e pranueshëm të lexuesve, datën e krijimit dhe, idealisht, afatin e skadimit. Ruani këto metadata.

No, ne zbuluam se duhet të lëviznim skedarët…

Kjo është një nga arsyet më të çmuara. Shumë njerëz nuk e dinë se serverët e uebit ju lejojnë të menaxhoni lidhjen midis URI të objektit dhe vendndodhjes së tij reale në sistemin e skedarëve. Imagjinoni hapësirën URI si një hapësirë abstrakte, të organizuar perfekt. Pastaj bëni një mapim në çdo realitet që përdorni për ta zbatuar atë. Më pas informoni serverin e uebit për këtë. Ju mund të shkruani madje një fragment të serverit tuaj, për ta bërë gjithçka siç duhet.

John nuk e mbështet më këtë skedar, tani e bën Jane.

Ishte emri i John në URI? Jo, thjesht skedari ndodhej në direktorinë e tij? E kuptoj.

Deri më tani kemi përdorur një skript CGI për këtë, tani përdorim një program binar.

Ka një ide të çmendur që faqet e krijuara nga skriptet duhet të jenë në zonën "cgibin" ose "cgi". Kjo ndihmon në zbërthimin e mekanizmit se si e drejtoni serverin tuaj web. Ndryshoni mekanizmin (edhe duke ruajtur përmbajtjen), dhe ups — të gjithë URI-t tuaj ndryshojnë.

Të marrim, për shembull, Fondin Kombëtar të Shkencës (NSF):

Dokumentet online të NSF

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

Faqja e parë për të filluar shikimin e dokumenteve nuk do të mbetet e njëjtë pas disa vitesh. cgi-bin, oldbrowse dhe pl — të gjitha këto japin fragmente informacioni rreth asaj se si-po-e-bejmë-këtë-tani. Nëse përdorni një faqe për të kërkuar një dokument, atëherë merrni një rezultat po aq të keq:

Raporti i grupit të punës për kriptologjinë dhe teorinë e kodimit

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

për faqen indeks të dokumentit, megjithatë vetë dokumenti html duket shumë më mirë:

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

Titulli këtu pubs/1998 do t'i japë çdo shërbimi të ardhshëm arkivor një çelës të mirë për të kuptuar se si funksionon ish skema e klasifikimit të dokumenteve të vitit 1998. Edhe pse në vitin 2098 numrat e dokumenteve mund të duken ndryshe, unë mund ta imagjinoj se ky URI do të jetë ende në fuqinë, dhe nuk do t'i pengojë NSF ose ndonjë organizatë tjetër që do të mbështesë arkivin.

Nuk e mendoja se URL-të duhet të ishin të përhershme — nuk ka qenë ndonjëherë URN.

Mund të jetë ndoshta një nga efektet më të këqija anësore të diskutimit mbi URN. Disa mendojnë se për shkak të kërkimeve për një hapësirë emri më të qëndrueshme mund të sillen ashtu siç iu pëlqen lidhjeve të varura, pasi "URN do ta zgjidhin këtë gjithçka". Nëse jeni një nga këta njerëz, lejoni të ju zhgënjej.

Shumica e skemave URN që kam parë duken si një identifikues autoriteti, të ndjekur nga një datë dhe një varg që ju zgjidhni, ose thjesht një varg që ju zgjidhni. Kjo është shumë e ngjashme me URI HTTP. Në fjalë të tjera, nëse mendoni se organizata juaj do të jetë në gjendje të krijojë URN të gjatë të jetesës, atëherë provojeni këtë tani duke i përdorur ato për URI-të tuaj HTTP. Në HTTP nuk ka asgjë që e bën URI-në tuaj të paqëndrueshme. Vetëm organizata juaj. Krijoni një bazë të dhënash që përputh URN-në e dokumentit me emrin aktual të skedarit dhe lejoni serverin web ta përdorë atë për të tërhequr skedarët faktikisht.

Nëse keni arritur deri në këtë pikë, atëherë nëse nuk keni kohë, para dhe lidhje për të zhvilluar ndonjë softuer, mund të bëni këtë justifikim:

Ne do të donim, por thjesht nuk kemi mjetet e nevojshme.

Këtij i ndihmon me keqardhje. Jam plotësisht dakord. Ajo që duhet të bëni është të bëni që serveri i uebit të procesojë menjëherë URI-në e vazhdueshme dhe të kthejë skedarin, pavarësisht se ku ruhet ai në momentin tuaj në sistemin tuaj të çfarëdolloj të çmendur të dosjeve. Ju dëshironi të ruani të gjitha URI-të në një skedar si një verifikim dhe të mbani vazhdimisht një databazë në përputhje me aktualitetin. Ju dëshironi të ruani marrëdhëniet midis versioneve dhe përkthimeve të ndryshme të të njëjtit dokument, si dhe të ruani një regjistër të pavarur të kontrolleve të shumave për të siguruar mbrojtje ndaj dëmtimeve të skedarit për shkak të një gabimi të rastësishëm. Dhe serverët e uebit thjesht nuk vijnë nga fabrika me këto funksionalitete. Kur dëshironi të krijoni një dokument të ri, redaktori juaj kërkon të vendosni URI-në.

Ju nevojitet mundësia për të ndryshuar pronësinë, aksesin në dokument, nivelin e sigurisë së arkivave dhe të tjera në hapësirën URI pa ndryshuar URI-në.

Gjithçka është shumë keq. Por ne do ta rregullojmë situatën. Në W3C ne përdorim funksionalitetin Jigedit (serveri Jigsaw për editimin), i cili ndjek versionet, dhe po eksperimentojmë me skriptet e krijimit të dokumenteve. Nëse po zhvilloni mjete, serverë dhe klientë, kushtojini vëmendje kësaj çështjeje!

Ky justifikim i referohet gjithashtu shumë faqeve të W3C, duke përfshirë këtë: prandaj bëni atë që them, jo atë që bëj.

Pse duhet të më shqetësojë kjo?

Kur ndryshoni URI-në në serverin tuaj, nuk mund ta thoni kurrë plotësisht se kush do të ketë lidhje me URI-në e vjetër. Këto mund të jenë lidhje nga faqe të zakonshme. Shënime në faqen tuaj. URI mund të ketë qenë i shkruar në margjinat e një letre për një mik.

Kur dikush ndjek një lidhje dhe ajo është e prishur, ai zakonisht humbet besimin te pronari i serverit. Ai gjithashtu ndjehet i zhgënjyer - emocionalisht dhe realisht për pamundësinë për të arritur qëllimin e tij.

Shumë njerëz ankohet vazhdimisht për lidhje të prishura, dhe shpresoj që dëmi të jetë i qartë. Shpresoj që gjithashtu të jetë e qartë dëmi reputacional për mbajtësin e serverit, ku dokumenti ka humbur.

Çfarë duhet të bëj? Dizajni i URI

Kjo është detyra e webmaster-it — të identifikojë URI-të që do të përdoren pas 2 vjetësh, pas 20 vjetësh, pas 200 vjetësh. Për këtë janë të nevojshme mendimi i mirë, organizimi dhe fokusi.

URI-të ndryshojnë nëse ndonjë informacion në to ndryshon. Është shumë e rëndësishme si i projektoni ato. (Çfarë, dizajnimi i URI-t? Duhet të mendoj për dizajnimin e URI-ve? Po, duhet të mendoni për këtë). Projektimi në thelb do të thotë të mos ketë ndonjë informacion në URI.

Data e krijimit të dokumentit — data e lëshimit të URI — është ajo që kurrë nuk do të ndryshojë. Ajo është shumë e dobishme për të ndarë kërkesat që përdorin sistemin e ri nga ato që përdorin sistemin e vjetër. Një fillim i mirë për URI. Nëse në dokument është vendosur një datë, edhe nëse dokumenti do të jetë i vlefshëm në të ardhmen, atëherë është një fillim i mirë.

Përjashtimi i vetëm është faqja që është qëllimisht versioni "më i fundit", për shembull, për tërë organizatën ose një pjesë të madhe të saj.

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

Ky është kolona e fundit e Money Daily në revistën Money. Arsyeja kryesore pse ky URI nuk ka nevojë për datë është se nuk ka arsye për të ruajtur një URI që do të overojë revistën. Koncepti i Money Daily do të zhduket kur të zhduket Money. Nëse dëshironi të referoheni përmbajtjes, duhet ta referoni atë veçmas në arkiva:

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

(Duket mirë. Supozon se "money" do të thotë të njëjtën gjë gjatë gjithë kohës së ekzistencës së pathfinder.com. Ka disa përsëritje "98" dhe një ".html" të panevojshëm, por përndryshe duket si një URI i fortë.

Çfarë të lësh mënjanë

Asgjë! Përveç datës së krijimit, duke vendosur çdo informacion në URI, në një mënyrë apo në një tjetër, po i jepni vetes probleme.

Emri i autorit. Autorship mund të ndryshojë me daljen në dritë të versioneve të reja. Njerëzit largohen nga organizatat dhe i kalojnë gjërat të tjerëve.
Subjekti. Kjo është shumë e vështirë. gjithmonë duket mirë në fillim, por ndryshon befas shpejt. Do të flas më shumë për këtë më poshtë.
Statusi. Katalogët si "të vjetrën", "skicë" dhe të tjerë, pa folur për "të fundit" dhe "cool", shfaqen në të gjitha sistemet e skedarëve. Dokumentet ndryshojnë statusin - ndryshe nuk do kishte kuptim të krijoheshin skicat. Versioni më i fundit i dokumentit kërkon një identifikues të vazhdueshëm, pavarësisht nga statusi i tij. Mbani statusin jashtë emrit.
Qasje. Në W3C ne e kemi ndarë faqen në seksione për punonjësit, anëtarët dhe publikun. Kjo tingëllon mirë, por, sigurisht, dokumentet fillojnë si ide të ekipit të punonjësve, diskutohet me anëtarët dhe pastaj bëhen të aksesueshme për publikun. Në fakt, është e bezdisshme që sa herë që ndonjë dokument hapet për një diskutim më të gjerë, të gjitha lidhjet e vjetra për të dështojnë! Tani po kalojmë në kodin e thjeshtë të dates.
Zgjatja e skedarit. Një fenomen shumë i zakonshëm. "cgi", madje ".html" do të ndryshojnë në të ardhmen. Ndoshta, pas 20 vjetësh nuk do të përdorni HTML për këtë faqe, por lidhjet e sotme për të ende duhet të funksionojnë. Lidhjet kanonike në faqen e W3C nuk përdorin zgjatjen (si bëhet kjo).
Mekanizmat Software. Në URI kërkoni "cgi", "exec" dhe terma të tjerë që thonë "shihni, çfarë software-i po përdorim". A do të donte dikush të ngrinte një jetë të tërë me skenarë Perl CGI? Jo? Atëherë hiqni zgjerimin .pl. Lexoni manualin e serverit se si ta bëni këtë.
Emri i diskut. Po, mirë! Por unë kam parë diçka të tillë.

Pra, shembulli më i mirë nga faqja jonë është thjesht

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

… raporti i protokollit të takimit të kryetarëve të W3C.

Temat dhe klasifikimi sipas temave

Do ta shpjegoj më në detaje këtë rrezik, pasi është një nga ato gjëra që është më e vështirë për t'u shmangur. Zakonisht, temat futen në URI kur klasifikoni dokumentet tuaja sipas punës që po kryeni. Por kjo ndarje do të ndryshojë me kalimin e kohës. Emrat e fushave do të ndryshojnë. Në W3C dëshironim ta ndryshonim MarkUP në Markup dhe më pas në HTML, për të reflektuar përmbajtjen reale të seksionit. Për më tepër, shpesh këtu është një hapësirë e planit të sheshtë. Pas 100 vjetësh, jeni të sigurt se nuk do të donit të ripërdorni asgjë? Në jetën tonë të shkurtër tashmë kemi dashur të ripërdorim "Historinë" dhe "Tabelat e stileve", për shembull.

Kjo është një mënyrë tërheqëse për të organizuar një faqe interneti — dhe vërtet një mënyrë erësësishme për të organizuar gjithçka, përfshirë tërë Internetin. Kjo është një zgjidhje e shkëlqyer afatmesëm, por ka disa disavantazhe të rëndësishme në afat të gjatë.

Pjesërisht, arsyet ndodhen në filozofinë e kuptimit. Çdo term në gjuhë është një objekt potencial për grumbullim, dhe çdo individ mund të ketë një përceptim të ndryshëm për atë që do të thotë. Meqë marrëdhëniet midis subjekteve janë më shumë si një endje sesa si një pemë, edhe ata që bien dakord me endjen mund të zgjedhin një përfaqësim të ndryshëm të pemës. Këto janë shënimet e mia (shumë herë të përsëritura) rreth rreziqeve të klasifikimit hierarkik si një zgjidhje të përgjithshme.

Në fakt, kur përdorni emrin e temës në URI, ju lidhni veten me një klasifikim të caktuar. Ndoshta në të ardhmen do preferoni një variant tjetër. Atëherë URI do të jetë i prirur për shkelje.

Arsyja e përdorimit të temës në URI është se përgjegjësia për nënseksionet e hapësirës URI zakonisht delegohet, dhe atëherë ju nevojitet emri i organit organizativ — një nënseksi, grupi ose diçka tjetër që mban përgjegjësinë për këtë nënhapësirë. Ky është lidhja e URI me strukturën organizative. Zakonisht është e sigurt vetëm nëse më tutje (majtas) URI mbrohet nga data: 1998/pics mund të nënkuptojë për serverin tuaj "atë që patëm parasysh në vitin 1998 si pics", dhe jo "atë që bëmë në vitin 1998 me atë që tani e quajmë pics".

Mos harroni emrin e domeneve

Kujdes për t'u kujtuar se kjo i referohet jo vetëm rrugës në URI, por edhe emrit të serverit. Nëse keni serverë të ndarë për gjëra të ndryshme, mbani në mend se kjo ndarje do të jetë e pamundur për t'u ndryshuar pa shkatërruar shumë shumë lidhje. Disa gabime klasike si "shikoni se çfarë softueri po përdorim sot" — emrat e mundshme të domain-it "cgi.pathfinder.com", "secure", "lists.w3.org". Ato janë krijuar për të lehtësuar administrimin e serverëve. Pavarësisht nëse domeni përfaqëson ndonjë departament në kompaninë tuaj, statusin e dokumentit, nivelin e aksesit apo nivelin e sigurisë, kini kujdes shumë, shumë para se të përdorni më shumë se një emër domeni për disa lloje dokumentesh. Kujtoni se mund të fshehni shumë serverë web brenda një serveri web të dukshëm, duke përdorur ridrejtime dhe proxy.

Po, dhe mendoni edhe për emrin tuaj të domenit. Nuk doni që të referoheni si soap.com pasi të ndryshoni linjën e produkteve dhe të ndaloni së prodhuari sapunin (Kërkoj ndjesë nga ai që zotëron soap.com në këtë moment).

Përfundimi

Ruajtja e URI-ve për 2, 20, 200 ose madje 2000 vjet, duket se nuk është aq e lehtë sa duket. megjithatë, në të gjithë internetin webmasterët marrin vendime që vërtet e vështirësojnë këtë detyrë për të ardhmen. Kjo ndodhin shpesh sepse ata përdorin mjete, të cilat kanë si qëllim të paraqesin një faqe të shkëlqyer vetëm në këtë moment – dhe askush nuk e vlerësoi se çfarë do të ndodhë me lidhjet kur gjithçka të ndryshojë. Megjithatë, ideja këtu është se shumë, shumë gjëra mund të ndryshojnë, dhe URI-t tuaj mund dhe duhet të mbeten të njëjta. Kjo është e mundur vetëm kur mendoni për mënyrën se si i krijoni ato.

Shih gjithashtu:

Tiradë nga Jakob Nielsen mbi të njëjtën temë

Shtesa

Si të hiqni zgjerimet e skedarëve…

…nga URI në serverin aktual të webit në bazë të skedarëve?

Nëse po përdorni, për shembull, Apache, atëherë mund ta konfiguroni atë për të përputhur përmbajtjen. Ruani zgjerimin e skedarit (për shembull, .png) në skedarin (për shembull, mydog.png), porosinë e lidhjes në një burim web është e mundur dhe pa të. Më pas, Apache kontrollon katalogun për të gjetur të gjitha skedarët me këtë emër dhe çdo zgjerim, si dhe mund të zgjedhë më të mirin nga grupi (p.sh. GIF dhe PNG). Dhe nuk është e nevojshme të vendosni lloje të ndryshme skedarësh në katalogje të ndryshme, në të vërtetë, pajtimi i përmbajtjes nuk do të funksionojë nëse e bëni këtë.

Konfiguroni serverin tuaj për pajtimin e përmbajtjes
Gjithmonë krijoni lidhje në URI pa zgjerim

Lidhjet me zgjerime ende do të punojnë, por nuk do të lejojnë serverin tuaj të zgjedhë më të mirët nga format aktuale dhe të ardhshme.

(Në të vërtetë, mydog, mydog.png dhe mydog.gif - burime të vlefshme web, mydog - kjo është një burim i tipit universale të përmbajtjes, dhe mydog.png dhe mydog.gif - burimet e tipit të veçantë të përmbajtjes).

Sigurisht, nëse po shkruani serverin tuaj të web-it, është e rekomandueshme të përdorni një bazë të dhënash për të lidhur identifikatorët e përhershëm me formën e tyre aktuale, megjithatë, kini kujdes nga rritja e pakufizuar e Bazës së të Dhënave.

Tabela e turpit - Historia 1: Channel 7

Gjatë vitit 1999, ndjekja e mbylljes së shkollave për shkak të borës në faqe http://www.whdh.com/stormforce/closings.shtml. Nuk është mirë të presësh që informacioni të shfaqet në fund të ekranit të televizorit! Unë vendosa një lidhje për të në faqen time të shtëpisë. Po vjen një stuhi e madhe bore në vitin 2000, dhe po kontrolloj faqen. Aty shkruhet:

— Sipas gjendjes.
Aktualisht nuk ka asgjë të mbyllur. Ju lutemi, kthehuni për paralajmërime të motit.

Nuk mund të jetë, një stuhi kaq e fortë. Është qesharake që data mungon. Por nëse kalon në faqen kryesore të sitit, atje do të gjeni një buton të madh «Shkollat e mbyllura», i cili drejton në një faqe http://www.whdh.com/stormforce/ me një listë të gjatë të shkollave të mbyllura.

Ndoshta ata ndryshuan sistemin për të marrë listën — por nuk kishin nevojë ta ndryshonin URI-në.

Tabela e turpit — Historia 2: Microsoft Netmeeting

Me rritjen e varësisë nga interneti erdhi një mendim i zgjuar, që aplikacionet mund të inkorporojnë lidhje me faqen e prodhuesit. Kjo shpesh është përdorur dhe abuzuar rëndë, por — nuk mund ta ndryshosh URL-në. Pjesërisht dje provoja një lidhje nga klienti Microsoft Netmeeting 2/something në menunë Help/Microsoft on the Web/Free stuff dhe mora një gabim 404 — nuk u gjet përgjigja nga serveri. Ndoshta e kanë rregulluar tashmë…

Shënim historik: në fund të shekullit të 20-të, kur kjo u shkrua, "cool" ishte një epitet miratimi, veçanërisht mes rinisë, duke treguar për modën, cilësinë ose praktikshmërinë. Në të rush, rruga URI shpesh zgjidhej për "coolness", e jo për përdorshmëri ose qëndrueshmëri. Ky shënim është një përpjekje për të ridrejtuar energjinë që qëndron pas kërkimit të 'cool-ës'.

Burimi: habr.com