Autori: Sir Tim Berners-Lee, shpikësi i URI-ve, URL-ve, HTTP, HTML dhe World Wide Web, dhe kreu aktual i W3C. Artikull i shkruar në 1998

Cili URI konsiderohet "i lezetshëm"?
Një që nuk ndryshon.
Si ndryshohen URI-të?
URI-të nuk ndryshojnë: njerëzit i ndryshojnë ato.

Në teori, nuk ka asnjë arsye që njerëzit të ndryshojnë URI-të (ose të ndalojnë dokumentet mbështetëse), por në praktikë ka miliona prej tyre.

Në teori, pronari nominal i hapësirës së emrave të domenit zotëron në të vërtetë hapësirën e emrave të domenit dhe për rrjedhojë të gjitha URI-të brenda tij. Përveç falimentimit, asgjë nuk e pengon pronarin e një emri domain-i të mbajë emrin. Dhe në teori, hapësira URI nën emrin tuaj të domenit është tërësisht nën kontrollin tuaj, kështu që ju mund ta bëni atë aq të qëndrueshme sa të doni. Pothuajse e vetmja arsye e mirë që një dokument të zhduket nga interneti është se kompania që zotëronte emrin e domenit ka dalë jashtë biznesit ose nuk mund të përballojë më të mbajë serverin në punë. Atëherë pse ka kaq shumë hallka që mungojnë në botë? Disa nga këto janë thjesht mungesë paramendimi. Këtu janë disa arsye që mund të dëgjoni:

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

A mendoni vërtet që URI-të e vjetra nuk mund të funksionojnë më? Nëse po, atëherë i keni zgjedhur shumë keq. Konsideroni të mbani të rejat për ridizajnimin e ardhshëm.

Kemi aq shumë gjëra saqë nuk mund të mbajmë gjurmët e asaj që është e vjetëruar, e asaj që është konfidenciale dhe e asaj që është ende e rëndësishme, kështu që menduam se ishte më mirë t'i çaktivizonim të gjitha.

Unë vetëm mund të simpatizoj. W3C kaloi një periudhë ku ne duhej të analizonim me kujdes materialet arkivore për konfidencialitet përpara se t'i bënim ato publike. Vendimi duhet të mendohet paraprakisht - sigurohuni që me çdo dokument të regjistroni lexuesit e pranueshëm, datën e krijimit dhe, në mënyrë ideale, datën e skadimit. Ruani këto meta të dhëna.

Epo, ne zbuluam se duhet të zhvendosim skedarët...

Ky është një nga justifikimet më patetike. Shumë njerëz nuk e dinë se serverët e uebit ju lejojnë të kontrolloni marrëdhënien midis URI-së së një objekti dhe vendndodhjes së tij aktuale në sistemin e skedarëve. Mendoni për hapësirën URI si një hapësirë abstrakte, të organizuar në mënyrë perfekte. Pastaj bëni një hartë të çfarëdo realiteti që përdorni në të vërtetë për ta realizuar atë. Pastaj raportojeni këtë te serveri i uebit. Ju madje mund të shkruani fragmentin e serverit tuaj për ta marrë atë siç duhet.

Gjoni nuk e ruan më këtë skedar, Xhejni tani.

A ishte emri i Gjonit në URI? Jo, a ishte skedari vetëm në drejtorinë e tij? Epo, në rregull.

Më parë kemi përdorur një skript CGI për këtë, por tani përdorim një program binar.

Ekziston një ide e çmendur që faqet e krijuara nga skriptet duhet të vendosen në zonën "cgibin" ose "cgi". Kjo ekspozon mekanikën se si e drejtoni serverin tuaj të internetit. Ju ndryshoni mekanizmin (edhe kur ruani përmbajtjen) dhe oops - të gjitha URI-të tuaja ndryshojnë.

Merrni për shembull Fondacionin Kombëtar të Shkencës (NSF):

Dokumentet NSF Online

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 и pl - e gjithë kjo jep informacione rreth asaj se si e bëjmë tani. Nëse përdorni faqen për të kërkuar një dokument, rezultati i parë që merrni është po aq i keq:

Raport i Grupit Punues për Kriptologjinë dhe Teorinë e Kodimit

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

për faqen e indeksit të dokumentit, megjithëse vetë dokumenti html duket shumë më mirë:

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

Këtu, titulli "pubs/1998" do t'i japë çdo shërbimi të ardhshëm arkivor një të dhënë të mirë se skema e vjetër e klasifikimit të dokumenteve të vitit 1998 është në fuqi. Megjithëse numrat e dokumenteve mund të duken të ndryshëm në 2098, unë do të imagjinoja që kjo URI do të ishte ende e vlefshme dhe nuk do të ndërhynte me NSF ose ndonjë organizatë tjetër që do të ruante arkivin.

Nuk mendoja se URL-të duhej të ishin të qëndrueshme - kishte URN.

Ky është ndoshta një nga efektet anësore më të këqija të debatit URN. Disa njerëz mendojnë se për shkak të kërkimit në një hapësirë emri më të përhershme, ata mund të jenë të pakujdesshëm për lidhjet e varura sepse "URN-të do ta rregullojnë të gjithë këtë." Nëse jeni një nga këta njerëz, atëherë më lejoni t'ju zhgënjej.

Shumica e skemave URN që kam parë duken si një identifikues autoriteti i ndjekur nga një datë dhe një varg që zgjidhni, ose thjesht një varg që zgjidhni. Kjo është shumë e ngjashme me një URI HTTP. Me fjalë të tjera, nëse mendoni se organizata juaj do të jetë e aftë të krijojë URN jetëgjatë, atëherë provojeni tani duke i përdorur ato për URI-të tuaja HTTP. Nuk ka asgjë në vetë HTTP që e bën URI-në tuaj të paqëndrueshme. Vetëm organizata juaj. Krijoni një bazë të dhënash që harton URN-në e dokumentit me emrin aktual të skedarit dhe lëreni serverin e uebit ta përdorë atë për të rimarrë skedarët.

Nëse keni arritur në këtë pikë, nëse nuk keni kohë, para dhe lidhje për të zhvilluar disa softuer, atëherë mund të jepni justifikimin e mëposhtëm:

Ne donim, por thjesht nuk kemi mjetet e duhura.

Por ju mund të simpatizoni këtë. Jam plotësisht dakord. Ajo që duhet të bëni është të detyroni serverin e uebit të analizojë në çast URI-në e vazhdueshme dhe ta kthejë skedarin kudo që ruhet aktualisht në sistemin tuaj aktual të çmendur të skedarëve. Ju dëshironi të ruani të gjitha URI-të në një skedar si një kontroll dhe ta mbani bazën e të dhënave të përditësuar në çdo kohë. Ju dëshironi të ruani marrëdhënien midis versioneve të ndryshme dhe përkthimeve të të njëjtit dokument, dhe gjithashtu të mbani një regjistrim të pavarur të kontrollit për të siguruar që skedari të mos korruptohet nga një gabim aksidental. Dhe serverët e uebit thjesht nuk dalin nga kutia me këto veçori. Kur dëshironi të krijoni një dokument të ri, redaktori juaj ju kërkon të specifikoni një URI.

Ju duhet të jeni në gjendje të ndryshoni pronësinë, qasjen në dokumente, sigurinë e nivelit të arkivit, etj. në hapësirën URI pa ndryshuar URI-në.

Është e gjitha shumë keq. Por ne do ta korrigjojmë situatën. Në W3C, ne përdorim funksionalitetin Jigedit (server redaktues Jigsaw) që gjurmon versionet dhe eksperimentojmë me skriptet e gjenerimit të dokumenteve. Nëse zhvilloni mjete, serverë dhe klientë, kushtojini vëmendje kësaj çështje!

Ky justifikim vlen edhe për shumë faqe W3C, duke përfshirë këtë: kështu që bëj si them unë, jo si bëj unë.

Pse duhet të kujdesem?

Kur ndryshoni URI-në në serverin tuaj, nuk mund të dalloni kurrë plotësisht se kush do të ketë lidhje me URI-në e vjetër. Këto mund të jenë lidhje nga faqet e zakonshme të internetit. Shënoni faqen tuaj. URI mund të jetë skalitur në kufijtë e një letre drejtuar një shoku.

Kur dikush ndjek një lidhje dhe ajo prishet, ata zakonisht humbasin besimin te pronari i serverit. Ai është gjithashtu i frustruar, emocionalisht dhe fizikisht, duke mos arritur të arrijë qëllimin e tij.

Shumë njerëz ankohen për lidhje të prishura gjatë gjithë kohës dhe shpresoj që dëmi të jetë i dukshëm. Shpresoj që dëmtimi i reputacionit të mirëmbajtësit të serverit ku dokumenti u zhduk të jetë gjithashtu i dukshëm.

Pra, çfarë duhet të bëj? Dizajni URI

Është përgjegjësi e webmasterit të ndajë URI-të që mund të përdoren në 2 vjet, në 20 vjet, në 200 vjet. Kjo kërkon kujdes, organizim dhe vendosmëri.

URI-të ndryshojnë nëse ndonjë informacion në to ndryshon. Mënyra se si i dizajnoni ato është shumë e rëndësishme. (Çfarë, dizajni URI? A duhet të dizajnoj URI-në? Po, duhet të mendoni për këtë). Dizajni në thelb nënkupton lënien jashtë çdo informacioni në URI.

Data e krijimit të dokumentit - data kur u lëshua URI - është diçka që nuk do të ndryshojë kurrë. Është shumë i dobishëm për ndarjen e pyetjeve që përdorin sistemin e ri nga ato që përdorin sistemin e vjetër. Ky është një vend i mirë për të filluar me një URI. Nëse një dokument është i datës, edhe nëse dokumenti do të jetë i rëndësishëm në të ardhmen, atëherë ky është një fillim i mirë.

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

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

Kjo është rubrika e fundit e Money Daily në revistën Money. Arsyeja kryesore që nuk ka nevojë për një datë në këtë URI është se nuk ka asnjë arsye për të ruajtur URI që do të jetë më e gjatë se regjistri. Koncepti i Money Daily do të zhduket kur Paraja të zhduket. Nëse dëshironi të lidheni me përmbajtjen, duhet ta lidhni atë veçmas në arkiva:

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

(Duket mirë. Supozon se "para" do të thotë të njëjtën gjë gjatë gjithë jetës së pathfinder.com. Ekziston një dublikatë "98" dhe një ".html" e panevojshme, por përndryshe duket si një URI e fortë.

Çfarë duhet lënë mënjanë

Të gjitha! Përveç datës së krijimit, vendosja e çdo informacioni në URI kërkon probleme në një mënyrë ose në një tjetër.

Emri i autorit. Autorësia mund të ndryshojë kur versionet e reja bëhen të disponueshme. Njerëzit largohen nga organizatat dhe ua kalojnë gjërat të tjerëve.
subjekt. Eshte shume e veshtire. Duket gjithmonë mirë në fillim, por ndryshon çuditërisht shpejt. Do të flas më shumë për këtë më poshtë.
Statusi. Drejtoritë si "e vjetër", "draft" dhe kështu me radhë, për të mos përmendur "të fundit" dhe "cool", shfaqen në të gjitha sistemet e skedarëve. Dokumentet ndryshojnë statusin - përndryshe nuk do të kishte asnjë pikë për të krijuar drafte. Versioni i fundit i një dokumenti ka nevojë për një identifikues të vazhdueshëm, pavarësisht nga statusi i tij. Mbajeni statusin jashtë emrit.
Aksesi. Në W3C, ne e kemi ndarë faqen në seksione për punonjësit, anëtarët dhe publikun. Kjo tingëllon mirë, por sigurisht që dokumentet fillojnë si ide ekipore nga stafi, diskutohen me anëtarët dhe më pas bëhen njohuri publike. Do të ishte vërtet turp nëse çdo herë që një dokument hapet për diskutim më të gjerë, prishen të gjitha lidhjet e vjetra të tij! Tani kalojmë te një kod i thjeshtë i datës.
Zgjatja e skedarit. Një dukuri shumë e zakonshme. "cgi", edhe ".html" do të ndryshojë në të ardhmen. Ju mund të mos përdorni HTML për këtë faqe për 20 vjet, por lidhjet e sotme me të duhet të funksionojnë akoma. Lidhjet kanonike në faqen e W3C nuk përdorin shtesën (si është bërë).
Mekanizmat e softuerit. Në URI, kërkoni "cgi", "exec" dhe terma të tjerë që bërtasin "shikoni se çfarë softueri po përdorim". A dëshiron dikush të kalojë gjithë jetën e tij duke shkruar skriptet Perl CGI? Jo? Pastaj hiqni shtesën .pl. Lexoni manualin e serverit se si ta bëni këtë.
Emri i diskut. Eja! Por unë e kam parë këtë.

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

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

... raport mbi procesverbalin e mbledhjes së Kryesuesve të W3C.

Temat dhe klasifikimi sipas tematikës

Do të hyj në detaje rreth këtij rreziku, pasi është një nga ato gjëra që është më e vështira për t'u shmangur. Në mënyrë tipike, temat përfundojnë në URI kur i kategorizoni dokumentet tuaja sipas punës që bëjnë. Por kjo ndarje do të ndryshojë me kalimin e kohës. Emrat e zonave do të ndryshojnë. Në W3C ne donim të ndryshonim MarkUP në Markup dhe më pas në HTML për të pasqyruar përmbajtjen aktuale të seksionit. Përveç kësaj, shpesh ka një hapësirë të sheshtë emri. Në 100 vjet, a jeni i sigurt se nuk do të dëshironi të ripërdorni asgjë? Në jetën tonë të shkurtër, ne tashmë kemi dashur të ripërdorim "Historinë" dhe "Fletët e stilit" për shembull.

Është një mënyrë joshëse për të organizuar një faqe interneti - dhe një mënyrë vërtet joshëse për të organizuar çdo gjë, duke përfshirë të gjithë Ueb-in. Kjo është një zgjidhje e shkëlqyer afatmesme, por ka mangësi serioze në planin afatgjatë.

Një pjesë e arsyes qëndron në filozofinë e kuptimit. Çdo term në një gjuhë është një objektiv i mundshëm për grupim, dhe çdo person mund të ketë një ide të ndryshme se çfarë do të thotë. Meqenëse marrëdhëniet midis entiteteve janë më shumë si një rrjetë sesa një pemë, edhe ata që pajtohen me rrjetin mund të zgjedhin një paraqitje të ndryshme të pemës. Këto janë vëzhgimet e mia (shpesh të përsëritura) të përgjithshme rreth rreziqeve të klasifikimit hierarkik si një zgjidhje e përgjithshme.

Në fakt, kur përdorni një emër teme në një URI, ju po angazhoheni për një lloj klasifikimi. Ndoshta në të ardhmen do të preferoni një opsion tjetër. URI më pas do të jetë i ndjeshëm ndaj shkeljes.

Arsyeja për përdorimin e një zone lënde si pjesë e një URI është se përgjegjësia për nënseksionet e hapësirës URI zakonisht delegohet, dhe më pas ju nevojitet emri i trupit organizativ - departamenti, grupi ose çfarëdo tjetër - që është përgjegjës për atë nënhapësirë. Ky është një URI i detyrueshëm për një strukturë organizative. Zakonisht është e sigurt vetëm nëse URI-ja e mëtejshme (majtas) mbrohet nga një datë: 1998/fotot mund të nënkuptojnë për serverin tuaj "çfarë nënkuptuam në 1998 me fotot" në vend të "ajo që bëmë në 1998 me atë që tani i quajmë foto".

Mos harroni emrin e domenit

Mos harroni se kjo vlen jo vetëm për shtegun në URI, por edhe për emrin e serverit. Nëse keni serverë të veçantë për gjëra të ndryshme, mbani mend se kjo ndarje do të jetë e pamundur të ndryshohet pa shkatërruar shumë e shumë lidhje. Disa gabime klasike "shikoni softuerin që përdorim sot" janë emrat e domeneve "cgi.pathfinder.com", "secure", "lists.w3.org". Ato janë krijuar për të bërë më të lehtë administrimin e serverit. Pavarësisht nëse një domen përfaqëson një ndarje në kompaninë tuaj, një status dokumenti, një nivel aksesi ose një nivel sigurie, jini shumë, shumë të kujdesshëm përpara se të përdorni më shumë se një emër domaini për lloje të shumta dokumentesh. Mos harroni se mund të fshehni shumë serverë ueb brenda një serveri të vetëm të dukshëm në internet duke përdorur ridrejtimin dhe proxying.

Oh, dhe gjithashtu mendoni për emrin e domenit tuaj. Ju nuk dëshironi të referoheni si soap.com pasi të ndryshoni linjat e produkteve dhe të ndaloni së prodhuari sapun (Na falni kujtdo që zotëron soap.com për momentin).

Përfundim

Ruajtja e një URI për 2, 20, 200 apo edhe 2000 vjet nuk është padyshim aq e lehtë sa duket. Megjithatë, në të gjithë internetin, webmasterët po marrin vendime që po e bëjnë këtë detyrë vërtet të vështirë për veten e tyre në të ardhmen. Shpesh kjo ndodh sepse ata përdorin mjete, detyra e të cilave është të paraqesin faqen më të mirë vetëm për momentin - dhe askush nuk e ka vlerësuar se çfarë do të ndodhë me lidhjet kur gjithçka të ndryshojë. Sidoqoftë, çështja këtu është se shumë, shumë gjëra mund të ndryshojnë, dhe URI-të tuaja mund dhe duhet të mbeten të njëjta. Kjo është e mundur vetëm kur mendoni se si i krijoni ato.

Shih gjithashtu:

Tirada e Jakob Nielsen për të njëjtën temë

Supplements

Si të hiqni shtesat e skedarëve...

...nga një URI në serverin aktual të uebit të bazuar në skedarë?

Nëse përdorni Apache, për shembull, mund ta konfiguroni atë për të negociuar përmbajtjen. Ruani shtesën e skedarit (p.sh. .png) në një skedar (p.sh. mydog.png), por ju mund të lidheni me një burim ueb pa të. Apache më pas kontrollon direktorinë për të gjithë skedarët me atë emër dhe çdo shtesë, dhe mund të zgjedhë më të mirën nga grupi (për shembull, GIF dhe PNG). Dhe nuk ka nevojë të vendosni lloje të ndryshme skedarësh në drejtori të ndryshme, në fakt përputhja e përmbajtjes nuk do të funksionojë nëse e bëni këtë.

Vendosni serverin tuaj për të negociuar përmbajtjen
Gjithmonë lidheni me URI-të pa shtrirje

Lidhjet me shtesa do të vazhdojnë të funksionojnë, por do të pengojnë serverin tuaj të zgjedhë formatin më të mirë të disponueshëm aktualisht dhe në të ardhmen.

(Në fakt, mydog, mydog.png и mydog.gif - burime të vlefshme të internetit, mydog është një burim universal i llojit të përmbajtjes dhe mydog.png и mydog.gif — burime të një lloji të caktuar përmbajtjeje).

Sigurisht, nëse jeni duke shkruar serverin tuaj të internetit, është mirë të përdorni një bazë të dhënash për të lidhur identifikuesit e vazhdueshëm me formën e tyre aktuale, megjithëse kini kujdes nga rritja e pakufizuar e bazës së të dhënave.

Bordi i Turpit - Historia 1: Kanali 7

Gjatë vitit 1999, unë gjurmova mbylljet e shkollave për shkak të borës në faqe http://www.whdh.com/stormforce/closings.shtml. Mos prisni që informacioni të shfaqet në fund të ekranit të televizorit! Unë u lidha me të nga faqja ime kryesore. Mbërrin stuhia e parë e madhe e borës së vitit 2000 dhe unë kontrolloj faqen. Aty shkruhet:

- Sa i përket.
Asgjë nuk është e mbyllur aktualisht. Ju lutemi kthehuni në rast të paralajmërimeve të motit.

Nuk mund të jetë një stuhi kaq e fortë. Është qesharake që mungon data. Por nëse shkoni në faqen kryesore të faqes, do të ketë një buton të madh "Shkollat e mbyllura", i cili të çon në faqe http://www.whdh.com/stormforce/ me një listë të gjatë shkollash të mbyllura.

Ndoshta ata ndryshuan sistemin për marrjen e listës - por ata nuk kishin nevojë të ndryshonin URI-në.

Board of Shame - Story 2: Microsoft Netmeeting

Me rritjen e varësisë nga interneti, erdhi një ide e zgjuar që lidhjet në faqen e internetit të prodhuesit mund të futeshin në aplikacione. Kjo është përdorur dhe abuzuar shumë, por ju nuk mund ta ndryshoni URL-në. Vetëm një ditë tjetër provova një lidhje nga klienti i Microsoft Netmeeting 2/something në menunë Help/Microsoft në ueb/Free stuff dhe mora një gabim 404 - nuk u gjet asnjë përgjigje nga serveri. Ndoshta tashmë është rregulluar ...

Shënim historik: Në fund të shekullit të 20-të, kur u shkrua kjo, "cool" ishte një epitet i miratimit, veçanërisht tek të rinjtë, që tregonte modën, cilësinë ose përshtatshmërinë. Me nxitim, rruga URI shpesh zgjidhej për "freski" dhe jo për dobinë ose qëndrueshmërinë. Ky postim është një përpjekje për të ridrejtuar energjinë që qëndron pas kërkimit për "cool".

Burimi: www.habr.com

URI-të e lezetshme nuk ndryshojnë