Autori — sir Tim Berners-Lee, shpikësi i URI, URL, HTTP, HTML dhe Internetit, drejtori aktual i W3C. Artikulli është shkruar në vitin 1998

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

Teoretikisht, njerëzit nuk kanë asnjë arsye për të ndryshuar URI-të (ose për të ndaluar mbështetjen për dokumentet), por në praktikë ka miliona.

Teoretikisht, pronari nominal i hapësirës së emrave të domain-it vërtet zotëron hapësirën e emrave të domenit dhe, për pasojë, të gjitha URI-të në të. Përveç falimentimit, asgjë nuk ndalon pronarin e emrit të domain-it të ruajë atë emër. Dhe teoretikisht, hapësira URI nën emrin tuaj të domain-it është plotësisht nën kontrollin tuaj, kështu që mund ta bëni kaq stabil sa të dëshironit. Në masë të madhe, arsyeja e vetme e qëndrueshme për zhdukjën e një dokumenti nga interneti është se kompania që e kishte emrin e domenit doli nga biznesi ose nuk mund ta përballonte më mbështetje e serverit. Pse ka kaq shumë lidhje të humbura në botë? Pjesërisht, kjo është thjesht një mungesë parashikimi. Këtu janë disa arsye që mund të dëgjoni:

Ne thjesht e kemi ri-organizuar faqen për ta bërë atë më të mirë.

A vërtet mendoni se URI-të e vjetër nuk funksionojnë më? Nëse po, atëherë i keni zgjedhur ato shumë keq. Mendoni të ruani të rejat pas dizajnit të ardhshëm.

Kemi aq shumë material, sa nuk mund të ndjekim se çfarë është e përjetshme, çfarë është konfidenciale dhe çfarë është ende relevante, dhe prandaj menduam se ishte më mirë thjesht t'i fiknim të gjitha këto.

Mund vetëm të ndjej keqardhje. W3C ka kaluar një periudhë kur na duhej të përgatisnim me kujdes materialet arkivore për çështjen e privatësisë para se t'i nxirrnim ato në dukje. Zgjidhja duhet të jetë e menduar në parakohësisht - sigurohuni që regjistroni me çdo dokument një rreth të pranueshëm lexuesish, datën e krijimit dhe, idealisht, kohëzgjatjen. Ruani këto metadata.

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

Ky është një nga justifikimet më të varfër. Shumë nuk e dinë se serverët web ju lejojnë të menaxhoni lidhjen midis URI-t të objektit dhe vendndodhjes së tij aktuale në sistemin e skedarëve. Imagjinoni hapësirën URI si një hapësirë abstrakte, të organizuar në mënyrë perfekte. Pastaj bëni një mapim në çdo realitet që në të vërtetë po e përdorni për ta realizuar atë. Më pas, njoftoni serverin web për këtë. Mund të shkruani edhe një fragment të serverit tuaj për ta bërë gjithçka të saktë.

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

A ishte emri i Xhonit në URI? Jo, thjesht skedari ndodhej në direktorinë e tij? E kuptoj.

Dikur e përdornim një CGI-skript për këtë, tani përdorim një program të parë.

Ka një ide të çmendur që faqet e krijuara nga skriptet duhet të vendosen në zonën "cgibin" ose "cgi". Kjo zbulon mekanizmin e mënyrës se si e aktivizoni serverin tuaj web. Ndryshoni mekanizmin (madje duke ruajtur përmbajtjen), dhe ops — të gjitha URI-t tuaja 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 sigurisht që nuk do të mbetet e tillë pas disa vitesh. cgi-bin, oldbrowse dhe pl — e gjithë kjo jep grimca informacioni se si-ne-e-bëjmë-këtë-tani. Nëse përdorni një faqe për të gjetur një dokument, atëherë rezultati i parë do të jetë gjithashtu po aq i keq:

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

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

për faqen indekse të dokumentit, ndonë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 ofrojë çdo shërbimi të arkivimit të ardhshëm një çelës të mirë për të kuptuar se çfarë vepron skema e vjetër e klasifikimit të dokumenteve të vitit 1998. Edhe pse në vitin 2098 numrat e dokumenteve mund të duken ndryshe, mund të imagjinoj se ky URI do të jetë ende i vlefshëm, dhe nuk do t'i bëjë dëm NSF-së ose ndonjë organizate tjetër që do ta mbështesë arkivin.

Nuk mendoja se URL-të duhej të ishin të përjetshme — ishin URN.

Mundësisht, ky është një nga efekte më të këqija anësore të diskutimit mbi URN. Disa mendojnë se për shkak të kërkimeve mbi një hapësirë më të përjetshme emri, ata mund ta trajtojnë papërgjegjshëm lidhjet e varura, pasi "URN do ta zgjidhin gjithçka". Nëse jeni një nga këta njerëz, le të ju zhgënjej.

Shumë skema URN që kam parë duken si një identifikues autoriteti, pasuar ose nga data dhe një varg që zgjidhni, ose thjesht nga një varg që zgjidhni. Kjo është shumë e ngjashme me URI-në HTTP. Në fjalë të tjera, nëse mendoni se organizata juaj do të jetë në gjendje të krijojë URN të përjetshme, atëherë provoje këtë tani, duke i përdorur ato për URI-të tuaja HTTP. Në vetë 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ë lidh URN e dokumentit me emrin aktual të skedarit dhe lejoni serverin tuaj web ta përdorë atë për të nxjerrë skedarët aktualë.

Nëse keni arritur deri këtu, atëherë nëse nuk keni kohë, para dhe lidhje për të zhvilluar ndonjë software, mund të deklaroni justifikimin e mëposhtëm:

Ne do të donim, por thjesht nuk kemi instrumentet e duhura.

Këtij mund t'i shprehim keqardhje. Unë jam plotësisht dakord. Ajo që duhet të bëni është të bëni që serveri web të përfundojë menjëherë URI-në e përhershme dhe të kthejë skedarin, kudo që ai të jetë ruajtur aktualisht në sistemin tuaj të çmendur të skedarëve. Ju dëshironi të ruani të gjitha URI-të në një skedar si një verifikim dhe të mbani vazhdimisht bazën e të dhënave në përputhje me aktualitetin. Ju dëshironi të ruani marrëdhëniet midis versioneve dhe përkthimeve të njëjtit dokument, si dhe të ruani një regjistër të pavarur të kontrollit për të siguruar mbrojtje nga dëmtimi i skedarëve për shkak të gabimeve aksidentale. Dhe serverët web thjesht nuk dalin nga kutia me këto funksionalitete. Kur dëshironi të krijoni një dokument të ri, redaktori juaj kërkon të përcaktoni URI-në.

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

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

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

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

Kur të ndryshoni URI-në në serverin tuaj, kurrë nuk mund të thoni me siguri se kush do të ketë lidhje me URI-në e vjetër. Ato mund të jenë lidhje nga faqet e zakonshme të internetit. Shënime mbi faqet tuaja. URI mund të jetë shënuar në faqet e një letre dërguar një shoku.

Kur dikush kalon nëpër një lidhje dhe ajo është e thyer, ai zakonisht e humb besimin te pronari i serverit. Ai gjithashtu ndjehet i zhgënjyer - emocionalisht dhe realisht nga pamundësia për të arritur qëllimin e tij.

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

Pra, çfarë duhet të bëj? Dizajno URI-në.

Kjo është detyra e webmaster-it - të identifikojë URI-të që do të përdoren për 2 vjet, 20 vjet, 200 vjet. Për këtë nevojiten mendim, organizim dhe qëllim.

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

Data e krijimit të dokumentit - data e lëshimit të URI - është diçka që nuk do të ndryshojë kurrë. 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. E mira është të filloni me këtë datë për URI-në. Nëse në dokument ka një datë të caktuar, madje edhe nëse dokumenti do të jetë aktual në të ardhmen, atëherë kjo është një fillim i mirë.

Përjashtimi i vetëm është faqja që ka për qëllim të jetë versi "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ë kolona e fundit e Money Daily në revistën Money. Arsyetimi kryesor përse ky URI nuk ka nevojë për një datë është se nuk ka arsye për të ruajtur një URI që do të mbijetojë përtej revistës. Koncepti Money Daily do të zhduket kur Money të zhduket. Nëse dëshironi të referoni përmbajtjen, duhet ta referoni atë veçmas në arkivat:

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

(Duket mirë. Sugjeron që "money" do të thotë të njëjtën gjë gjatë gjithë ekzistencës së pathfinder.com. Ka një përsëritje të "98" dhe një ".html" të panevojshme, por përndryshe duket si një URI e fortë.

Çfarë të lënë mënjanë.

Gjithçka! Përveç datës së krijimit, duke vendosur ndonjë informacion në URI, ju me siguri po i kërkoni vështirësi.

Emri i autorit. Autorship can change with new versions. People leave organizations and pass things to others.
Subject. It's very complex. It always looks good at first, but changes surprisingly quickly. I will explain more about this below.
Status. Catalogs like "old", "draft", and so on, not to mention "latest" and "cool", appear in all file systems. Documents change status — otherwise, there would be no point in creating drafts. The latest version of the document needs a constant identifier, regardless of its status. Keep the status out of the name.
Qasje. At W3C, we divided the site into sections for staff, members, and the public. This sounds good, but of course, documents start as team ideas from staff, are discussed with members, and then become public. It is indeed frustrating when every time a document is opened for broader discussion, all old links to it break! Now, we turn to a simple date code.
File extension. Very common. "cgi", even ".html" will change in the future. Perhaps in 20 years you won't be using HTML for this page, but today's links to it should still work. Canonical links on the W3C site do not use the extension (how this is done).
Software mechanisms. In the URI, look for "cgi", "exec", and other terms that scream "look at what software we are using". Does anyone want to dedicate their entire life to Perl CGI scripts? No? Then remove the .pl extension. Read the server's guide on how to do this.
Drive name. Come on! But I've seen that.

So the best example from our site is simply

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

… the report on the proceedings of the W3C chairs.

Topics and classification by themes

Do të flas më në detaje për këtë rrezik, pasi është një nga gjërat më të vështira për t'u shmangur. Në përgjithësi, temat përfshihen në URI kur kategorizoni dokumentet tuaja sipas punëve të kryera. Por ky 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 pastaj në HTML, për të reflektuar përmbajtjen reale të seksionit. Për më tepër, shpesh ketu ka hapësirë të sheshtë emërimi. Pas 100 vjetësh, a jeni të sigurt se nuk do të doni të ripërdorni asgjë? Në jetën tonë të shkurtër, ne tashmë kemi dashur të ripërdorim "Historinë" dhe "Tabela e stilit", për shembull.

Kjo është një mënyrë tërheqëse për të organizuar një faqe të internetit - dhe në të vërtetë një mënyrë tërheqëse për të organizuar çfarëdo, përfshirë të gjithë rrjetin. Kjo është një zgjidhje e shkëlqyer në mes të afatshkurta, por ka disavantazhe të konsiderueshme në afat të gjatë.

Pjesërisht, arsyet janë të lidhura me filozofinë e kuptimit. Çdo term në gjuhë është një objekt potencial për klasterizim, dhe çdo person mund të ketë një interpretim të ndryshëm të asaj që do të thotë. Duke qenë se marrëdhëniet midis subjekteve janë më shumë si një merimangë sesa si një pemë, edhe ata që janë në një marrëveshje me merimangën mund të zgjedhin një interpretim tjetër të pemës. Këto janë shënime të mia (përherë të përsëritura) mbi rreziqet e klasifikimit hierarkik si një zgjidhje të përgjithshme.

Në fakt, kur përdorni emrin e temës në URI, ju angazhoheni në një klasifikim të caktuar. Ndoshta, në të ardhmen, do të preferoni një alternativë tjetër. Atëherë URI do të jetë i ekspozuar ndaj shkeljes.

Arsyeja për përdorimin e fushës tematike si pjesë e URI është se përgjegjësia për nënfushat e hapësirës URI zakonisht delegohet, dhe atëherë ju nevojitet emri i organit organizativ - nënsektori, grupi, ose ndonjë gjë tjetër që ka përgjegjësinë për këtë nënhapësirë. Ky është angazhimi i URI me strukturën organizative. Në përgjithësi, ajo është e sigurt vetëm kur më tutje (majtas) URI mbrohet nga një datë: 1998/pics mund të nënkuptojë për serverin tuaj "aty ku ne ishim në mendje në vitin 1998 me pics", e jo "ato që bëmë në vitin 1998 me atë që tani e quajmë pics."

Mos harroni emrin e domenit

Mos kujtoni se kjo i përket jo vetëm rrugës në URI, por edhe emrit të serverit. Nëse keni servera të ndarë për gjëra të ndryshme, kujtoni se ndarja e tillë nuk do të jetë e mundur të ndryshohet pa shkatërruar shumë, shumë lidhje. Disa gabime klasike si "shihni se cilin software po e përdorim sot" — emrat e domainit "cgi.pathfinder.com", "secure", "lists.w3.org". Janë krijuar për të lehtësuar administrimin e serverëve. Pavarësisht nëse domeni paraqet një nëndeg të kompanisë suaj, statusin e dokumentit, nivelin e aksesit ose nivelin e sigurisë, mos harroni të jeni shumë, shumë të kujdesshëm para se të përdorni më shumë se një emër domaini për lloje të ndryshme dokumentesh. Kujtoni se mund të fshihni shumë serverë web brenda një serveri web të dukshëm duke përdorur ridrejtimin dhe proxy.

Po, dhe gjithashtu mendoni për emrin tuaj të domainit. Nuk doni që t'ju referohen si soap.com pasi të ndryshoni linjën tuaj të produkteve dhe të lëvizni nga prodhimi i sapunit (Kërkoj falje për atë që zotëron soap.com në këtë moment).

Përfundim

Ruajtja e URI-së për 2, 20, 200 ose madje 2000 vjet, qartësisht, nuk është aq e thjeshtë, sa duket. Sidoqoftë, në të gjithë internetin webmasterët marrin vendime që vërtet e vështirësojnë këtë detyrë në të ardhmen. Kjo ndodh shpesh sepse ata përdorin mjete, të cilat kanë për qëllim të paraqesin një faqe të mirë vetëm në këtë moment – dhe askush nuk e ka vlerësuar se çfarë do të ndodhë me lidhjet kur gjithçka të ndryshojë. Por sensi 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:

Tirana e Jakob Nielsen mbi të njëjtën temë

Shtesat

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

…nga URI në serverin aktual web bazuar në skedare?

Nëse përdorni, për shembull, Apache, mund ta konfiguroni atë për të pajtuar përmbajtjen. Ruani zgjerimin e skedarit (p.sh., .png) në skedar (p.sh., mydog.png), porosie gjithashtu mund të referoheni në një burim web pa të. Më pas, Apache kontrollon direktoriumin për të gjetur të gjitha skedarët me këtë emër dhe çdo zgjatje, dhe gjithashtu mund të zgjedhë atë më të mirin nga një grup (p.sh., GIF dhe PNG). Dhe nuk është e nevojshme të vendosni lloje të ndryshme skedarësh në direktorë të ndryshëm, në të vërtetë, pajtueshmëria e përmbajtjes nuk do të funksionojë nëse e bëni këtë.

Konfiguroni serverin tuaj për pajtueshmërinë e përmbajtjes
Gjithmonë bëni lidhje në URI pa zgjatje

Lidhjet me zgjatje ende do të funksionojnë, por nuk do t'ia lejojnë serverit tuaj të zgjedhë më të mirin nga format e disponueshme tani dhe në të ardhmen.

(Në të vërtetë, mydog, mydog.png dhe mydog.gif — burime valide web, mydog — ky është një burim me tip përmbajtje universale, dhe mydog.png dhe mydog.gif — janë burime me tip përmbajtje specifike).

Sigurisht, nëse po shkruani një server web tuajin, është mirë të përdorni një bazë të dhënash për të lidhur identifikuesit e qëndrueshëm me formën e tyre aktuale, megjithatë, kujdesuni nga rritja e pakufizuar e DB.

Shkalla e turpit — Historia 1: Channel 7

Gjatë vitit 1999, unë ndjekja mbylljen e shkollave për shkak të borës në faqen http://www.whdh.com/stormforce/closings.shtml. Nuk prisja që informacioni të shfaqej në fund të ekranit të televizorit! I vendosa një lidhje nga faqja ime e internetit. Vjen stuhia e madhe e parë e borës për vitin 2000, dhe unë e kontrolloj faqen. Aty shkruhet:

— Sipas gjendjes.
Aktualisht, asgjë nuk është mbyllur. Ju lutemi, kthehuni në rastet e paralajmërimeve për mot.

Nuk mund të jetë, një stuhi po aq e fortë. Qesharake që data mungon. Por nëse shkoni në faqen kryesore të sitit, atje do të ketë një buton të madh 'Shkollat e Mbyllura', i cili e çon në faqen http://www.whdh.com/stormforce/ me një listë të gjatë shkollash të mbyllura.

Ndoshta ata kanë ndryshuar sistemin për të marrë listën — por nuk ishte e nevojshme të ndryshonte URI.

Shkalla e turpit — Historia 2: Microsoft Netmeeting

Me varësinë e rritës nga interneti, erdhi një ide e zgjuar që lidhjet e prodhuesit mund të integrohen në aplikacione. Kjo është përdorur shpesh dhe abuzuar shumë, por — nuk duhet ndryshuar URL. Para disa ditësh, unë provoja një lidhje nga klienti Microsoft Netmeeting 2/something në menunë Ndihmë/Microsoft në Web/Gjërat falas, që çoi në një gabim 404 — nuk u gjet përgjigja nga serveri. Ndoshta, tashmë e kanë riparuar...

Shënim historik: në fund të shekullit të 20-të, kur u shkrua kjo, "cool" ishte një epitet miratimi, veçanërisht midis të rinjve, që tregonte për modën, cilësinë ose përshtatshmërinë. Në ngutësi, rruga URI shpesh u zgjodh për "coolness", jo për dobishmërinë ose qëndrueshmërinë. Ky shënim është një përpjekje për të ridrejtuar energjinë që qëndron pas kërkimit të coolness.

Burimi: habr.com