Szerző: Sir Tim Berners-Lee, az URI-k, URL-ek, HTTP, HTML és a World Wide Web feltalálója, a W3C jelenlegi vezetője. A cikk 1998-ban íródott

Melyik URI tekinthető "menőnek"?
Olyat, ami nem változik.
Hogyan változnak az URI-k?
Az URI-k nem változnak: az emberek megváltoztatják őket.

Elméletileg nincs ok arra, hogy az emberek megváltoztassák az URI-kat (vagy leállítsák az alátámasztó dokumentumokat), de a gyakorlatban több millió van belőlük.

Elméletileg egy tartománynévtér névleges tulajdonosa tulajdonképpen a tartomány névterének, és így a benne lévő összes URI-nek a tulajdonosa. A fizetésképtelenségen kívül semmi sem akadályozza meg a domain név tulajdonosát abban, hogy megtartsa a nevet. És elméletileg a domain neve alatti URI-terület teljes mértékben az Ön ellenőrzése alatt áll, így tetszés szerint stabillá teheti azt. Szinte az egyetlen jó oka annak, hogy egy dokumentum eltűnjön az internetről, az az, hogy a domain nevet birtokló cég megszűnt, vagy már nem engedheti meg magának, hogy a kiszolgálót tovább futtassa. Akkor miért van annyi hiányzó láncszem a világon? Ennek egy része egyszerűen az előrelátás hiánya. Íme néhány ok, amit hallhat:

Csak átszerveztük az oldalt, hogy jobb legyen.

Tényleg azt hiszi, hogy a régi URI-k már nem működnek? Ha igen, akkor nagyon rosszul választottad őket. Fontolja meg az újak megtartását a következő átalakításhoz.

Annyi cuccunk van, hogy nem tudjuk nyomon követni, mi az elavult, mi a bizalmas és mi a még aktuális, ezért jobbnak láttuk, ha kikapcsoljuk az egészet.

Csak együttérezni tudok. A W3C egy olyan időszakon ment keresztül, amikor gondosan át kellett vizsgálnunk az archív anyagokat a titoktartás érdekében, mielőtt nyilvánosságra hoztuk őket. A döntést előre át kell gondolni – ügyeljen arra, hogy minden dokumentumnál rögzítse az elfogadható olvasóközönséget, a keletkezési dátumot és ideális esetben a lejárati dátumot. Mentse el ezeket a metaadatokat.

Nos, rájöttünk, hogy át kell helyeznünk a fájlokat...

Ez az egyik legszánalmasabb kifogás. Sokan nem tudják, hogy a webszerverek lehetővé teszik az objektum URI-je és a fájlrendszerben való tényleges helye közötti kapcsolat szabályozását. Tekintsd az URI teret egy absztrakt térnek, tökéletesen szervezett. Ezután készítsen feltérképezést arra a valóságra, amelyet ténylegesen a megvalósításához használ. Ezután jelentse ezt a webszervernek. Akár saját szerverrészletet is írhat, hogy helyes legyen.

John már nem karbantartja ezt a fájlt, Jane már igen.

John neve szerepelt az URI-ban? Nem, a fájl csak az ő könyvtárában volt? Hát rendben.

Korábban CGI-szkriptet használtunk ehhez, most viszont bináris programot használunk.

Van egy őrült ötlet, hogy a szkriptek által létrehozott oldalak a "cgibin" vagy a "cgi" területen legyenek. Ez feltárja a webszerver futtatásának mechanikáját. Megváltoztatja a mechanizmust (még a tartalom mentése közben is), és hoppá - minden URI-je megváltozik.

Vegyük például a National Science Foundation-t (NSF):

NSF online dokumentumok

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

A dokumentumok megtekintésének első oldala nyilvánvalóan néhány éven belül nem marad ugyanaz. cgi-bin, oldbrowse и pl - mindez információfoszlányokat ad arról, hogy most hogyan csináljuk. Ha az oldalt egy dokumentum keresésére használja, az első találat ugyanilyen rossz:

A kriptológiai és kódoláselméleti munkacsoport jelentése

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

a dokumentum indexoldalához, bár maga a html dokumentum sokkal jobban néz ki:

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

Itt a pubs/1998 fejléc minden jövőbeni levéltári szolgálatnak jó jelzést ad arról, hogy a régi, 1998-as dokumentumosztályozási rendszer érvényben van. Bár a dokumentumszámok 2098-ban másképp nézhetnek ki, úgy gondolom, hogy ez az URI továbbra is érvényes lenne, és nem zavarná az NSF-et vagy bármely más, az archívumot karbantartó szervezetet.

Nem gondoltam, hogy az URL-eknek állandónak kell lenniük – voltak URN-ek.

Valószínűleg ez az URN-vita egyik legrosszabb mellékhatása. Vannak, akik úgy gondolják, hogy az állandóbb névtér kutatása miatt gondatlanok lehetnek a lógó hivatkozásokkal kapcsolatban, mert "az URN-ek mindent megoldanak." Ha te is ezek közé az emberek közé tartozol, hagyd, hogy csalódást okozzak.

A legtöbb általam látott URN-séma úgy néz ki, mint egy jogosultságazonosító, amelyet vagy egy dátum és egy kiválasztott karakterlánc követ, vagy csak egy kiválasztott karakterlánc. Ez nagyon hasonlít egy HTTP URI-hoz. Más szóval, ha úgy gondolja, hogy szervezete képes lesz hosszú élettartamú URN-ek létrehozására, akkor most bizonyítsa be a HTTP URI-k használatával. Magában a HTTP-ben nincs semmi, ami instabillá tenné az URI-t. Csak az Ön szervezete. Hozzon létre egy adatbázist, amely leképezi a dokumentum URN-jét az aktuális fájlnévre, és hagyja, hogy a webszerver felhasználja a fájlok tényleges lekéréséhez.

Ha eljutott idáig, ha nincs ideje, pénze és kapcsolata valamilyen szoftver fejlesztésére, akkor a következő kifogással élhet:

Szerettük volna, de nem rendelkezünk a megfelelő eszközökkel.

De ezzel együtt lehet érezni. Teljesen egyetértek. Amit tennie kell, az az, hogy rá kell kényszerítenie a webszervert, hogy azonnal elemezze az állandó URI-t, és visszaküldje a fájlt, bárhol is van az aktuális őrült fájlrendszerén. Az összes URI-t egy fájlban szeretné tárolni ellenőrzésként, és az adatbázist mindig naprakészen szeretné tartani. Meg akarja őrizni a kapcsolatot ugyanannak a dokumentumnak a különböző verziói és fordításai között, valamint egy független ellenőrzőösszeg-rekordot szeretne fenntartani annak biztosítására, hogy a fájlt ne sértse meg véletlen hiba. A webszerverek pedig egyszerűen nem jönnek ki ezekkel a funkciókkal. Ha új dokumentumot szeretne létrehozni, a szerkesztő kéri, hogy adjon meg egy URI-t.

Az URI-térben az URI megváltoztatása nélkül módosítani kell a tulajdonjogot, a dokumentum-hozzáférést, az archívum szintű biztonságot stb.

Nagyon rossz az egész. De javítjuk a helyzetet. A W3C-nél a Jigedit (Jigsaw Editing Server) funkciót használjuk, amely nyomon követi a verziókat, és kísérletezünk dokumentumgeneráló szkriptekkel. Ha eszközöket, szervereket és klienseket fejleszt, figyeljen erre a kérdésre!

Ez a kifogás sok W3C-oldalra is vonatkozik, beleértve ezt az oldalt is: tehát tedd azt, amit mondok, ne úgy, ahogy én teszem.

Miért érdekelne?

Amikor megváltoztatja az URI-t a kiszolgálón, soha nem tudja teljesen megmondani, hogy kinek lesz hivatkozása a régi URI-hoz. Ezek lehetnek normál weboldalak hivatkozásai. Könyvjelzővel jelölje meg oldalát. Lehet, hogy az URI-t egy barátjának írt levél margójára firkálták.

Amikor valaki követ egy linket, és az meghibásodik, általában elveszíti a kiszolgáló tulajdonosába vetett bizalmát. Érzelmileg és fizikailag is frusztrálja, hogy nem tudja elérni a célját.

Sokan folyamatosan panaszkodnak a hibás linkekre, és remélem, a kár nyilvánvaló. Remélem, hogy az a szerver karbantartójának hírneve is nyilvánvaló, ahol a dokumentum eltűnt.

Szóval mit tegyek? URI tervezés

A webmester felelőssége a 2 év, 20 év, 200 év múlva használható URI-k kiosztása. Ez átgondoltságot, szervezettséget és elszántságot igényel.

Az URI-k megváltoznak, ha bármilyen információ módosul bennük. Nagyon fontos, hogy hogyan tervezed őket. (Mi, URI tervezés? Meg kell terveznem az URI-t? Igen, ezen érdemes elgondolkodni). A tervezés alapvetően azt jelenti, hogy minden információt elhagyunk az URI-ban.

A dokumentum létrehozásának dátuma – az URI kiadásának dátuma – soha nem fog változni. Nagyon hasznos az új rendszert használó lekérdezések és a régi rendszert használó lekérdezések elkülönítésére. Ez egy jó hely az URI használatához. Ha egy dokumentum dátummal rendelkezik, még akkor is, ha a dokumentum releváns lesz a jövőben, akkor ez egy jó kezdet.

Az egyetlen kivétel az olyan oldal, amely szándékosan a "legújabb" verzió, például az egész szervezetre vagy annak nagy részére vonatkozóan.

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

Ez a Money magazin legújabb Money Daily rovata. A fő ok, amiért nincs szükség dátumra ebben az URI-ban, az az, hogy nincs ok az URI tárolására, amely túléli a naplót. A Money Daily fogalma eltűnik, amikor a pénz eltűnik. Ha tartalomra szeretne hivatkozni, az archívumban külön hivatkozzon rá:

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

(Jól néz ki. Feltételezi, hogy a "pénz" ugyanazt fogja jelenteni a pathfinder.com egész életében. Van egy "98" és egy szükségtelen ".html" másolat, de egyébként erős URI-nak tűnik.

Mit hagyjunk félre

Minden! A létrehozás dátumától eltekintve bármilyen információ elhelyezése az URI-ban, így vagy úgy gondot okoz.

• A szerző neve. A szerzőség megváltozhat, amint új verziók válnak elérhetővé. Az emberek kilépnek a szervezetekből, és átadják a dolgokat másoknak.
• téma. Ez nagyon nehéz. Elsőre mindig jól néz ki, de meglepően gyorsan változik. Erről az alábbiakban bővebben szólok.
• állapot. Az olyan könyvtárak, mint a "régi", "draft" és így tovább, nem beszélve a "legújabb" és a "cool" könyvtárakról, minden fájlrendszerben megjelennek. A dokumentumok állapota megváltozik – különben nem lenne értelme piszkozatokat készíteni. A dokumentum legújabb verziójának állandó azonosítóra van szüksége, függetlenül annak állapotától. Az állapot ne szerepeljen a névben.
• Hozzáférés. A W3C-nél az oldalt részekre osztottuk az alkalmazottak, a tagok és a nyilvánosság számára. Ez jól hangzik, de természetesen a dokumentumok a munkatársak csapatötleteként indulnak, megvitatják a tagokkal, majd nyilvánossá válnak. Valóban kár lenne, ha minden alkalommal, amikor egy dokumentumot szélesebb körű megvitatásra megnyitnának, az összes régi link megszakadna! Most áttérünk egy egyszerű dátumkódra.
• Fájlkiterjesztés. Nagyon gyakori jelenség. "cgi", még a ".html" is megváltozik a jövőben. Lehet, hogy 20 éve nem használ HTML-t ehhez az oldalhoz, de a mai linkeknek továbbra is működniük kell. A W3C webhely kanonikus hivatkozásai nem használják a kiterjesztést (hogyan készült).
• Szoftver mechanizmusok. Az URI-ban keresse a „cgi”, „exec” és más olyan kifejezéseket, amelyek „nézd meg, milyen szoftvert használunk”. Szeretné valaki egész életét Perl CGI szkriptek írásával tölteni? Nem? Ezután távolítsa el a .pl kiterjesztést. Olvassa el a szerver kézikönyvét, hogyan kell ezt megtenni.
• Lemez neve. Gyerünk! De ezt már láttam.

Tehát a legjobb példa oldalunkról egyszerűen

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

... jelentés a W3C elnökségi ülésének jegyzőkönyvéről.

Témák és témakörök szerinti osztályozás

Részletesebben kitérek erre a veszélyre, mivel ez az egyik legnehezebb elkerülni. A témák általában URI-kbe kerülnek, amikor a dokumentumokat az általuk végzett munka alapján kategorizálja. De ez a felosztás idővel változni fog. A területek neve megváltozik. A W3C-nél a MarkUP-ot Markup-ra, majd HTML-re akartuk változtatni, hogy tükrözze a szakasz tényleges tartalmát. Ezenkívül gyakran van egy lapos névtér. Biztos vagy benne, hogy 100 év múlva semmit sem akarsz újra felhasználni? Rövid életünk során már szerettük volna újra felhasználni például a "History"-t és a "Style Sheets"-t.

Csábító módja a webhelyek rendezésének – és igazán csábító módja bárminek, beleértve a teljes internetet is. Ez egy nagyszerű középtávú megoldás, de hosszú távon komoly hiányosságai vannak.

Az ok egy része a jelentésfilozófiában rejlik. Egy nyelvben minden kifejezés potenciális célpont a klaszterezéshez, és minden embernek más elképzelése lehet arról, hogy mit jelent. Mivel az entitások közötti kapcsolatok inkább hálóhoz, mint fához hasonlítanak, még azok is, akik egyetértenek a hálóval, választhatnak a fa más ábrázolását. Ezek az én (gyakran ismételt) általános megfigyeléseim a hierarchikus besorolás, mint általános megoldás veszélyeiről.

Valójában, ha témanevet használ egy URI-ban, akkor elkötelezi magát valamilyen osztályozás mellett. Talán a jövőben más lehetőséget választ majd. Az URI ekkor sérülni fog.

A tárgyterület URI részeként való használatának oka az, hogy az URI-terület alszakaszaiért való felelősséget általában delegálják, majd szükség van annak a szervezeti szervnek a nevére - osztály, csoport vagy bármi más -, amely az adott alterületért felelős. Ez egy szervezeti struktúrához kötődő URI. Általában csak akkor biztonságos, ha a további (bal oldali) URI-t dátum védi: az 1998/pics a szervere számára azt jelentheti, hogy „amit értünk 1998-ban a képekkel”, nem pedig azt, hogy „amit csináltunk 1998-ban azzal, amit ma képeknek hívunk”.

Ne felejtse el a domain nevet

Ne feledje, hogy ez nem csak az URI-ban lévő elérési útra vonatkozik, hanem a kiszolgáló nevére is. Ha külön szerverei vannak a különböző dolgokhoz, ne feledje, hogy ezt a felosztást lehetetlen megváltoztatni anélkül, hogy sok-sok linket megsemmisítenének. Néhány klasszikus "nézd meg a ma használt szoftvert" hiba a "cgi.pathfinder.com", "secure", "lists.w3.org" domain nevek. Úgy tervezték, hogy megkönnyítsék a szerver adminisztrációját. Függetlenül attól, hogy egy domain a vállalat egy részlegét, egy dokumentum állapotot, egy hozzáférési szintet vagy egy biztonsági szintet képvisel-e, legyen nagyon-nagyon körültekintő, mielőtt egynél több domain nevet használ több dokumentumtípushoz. Ne feledje, hogy átirányítás és proxy használatával több webszervert is elrejthet egyetlen látható webszerveren belül.

Ja, és gondoljon a domain nevére is. Nem szeretné, hogy a soap.com néven hivatkozzanak rád, miután megváltoztattad a termékcsaládot, és abbahagytad a szappankészítést (elnézést attól, aki jelenleg a soap.com tulajdonosa).

Következtetés

Egy URI-t 2, 20, 200 vagy akár 2000 évig megőrizni nyilvánvalóan nem olyan egyszerű, mint amilyennek látszik. Azonban az egész interneten a webmesterek olyan döntéseket hoznak, amelyek a jövőben nagyon megnehezítik ezt a feladatot. Ennek gyakran az az oka, hogy olyan eszközöket használnak, amelyeknek az a feladata, hogy csak az adott pillanatban a legjobb oldalt mutassák be – és senki sem mérte fel, mi lesz a hivatkozásokkal, ha minden megváltozik. Itt azonban az a lényeg, hogy sok-sok dolog változhat, és az URI-k változatlanok maradhatnak, és kell is maradniuk. Ez csak akkor lehetséges, ha átgondolja, hogyan hozza létre őket.

Lásd még:

• Jakob Nielsen tirádája ugyanerről a témáról

A kiegészítők

Hogyan lehet eltávolítani a fájlkiterjesztéseket...

...az aktuális fájl alapú webszerver URI-jéből?

Ha például Apache-t használ, beállíthatja a tartalom egyeztetésére. Mentse el a fájl kiterjesztését (pl. .png) egy fájlba (pl. mydog.png), de anélkül is linkelhet egy internetes forrást. Az Apache ezután ellenőrzi az összes ilyen nevű és bármilyen kiterjesztésű fájlt a könyvtárban, és kiválaszthatja a legjobbat a készletből (például GIF és PNG). És nem kell különböző típusú fájlokat különböző könyvtárakba helyezni, valójában a tartalomegyeztetés nem fog működni, ha így tesz.

• Állítsa be szerverét a tartalom egyeztetésére
• Mindig hivatkozzon az URI-kra kiterjesztés nélkül

A bővítményeket tartalmazó hivatkozások továbbra is működnek, de megakadályozzák, hogy a szerver a jelenleg és a jövőben elérhető legjobb formátumot válassza.

(Valójában, mydog, mydog.png и mydog.gif – érvényes webes források, mydog egy univerzális tartalom típusú erőforrás, és mydog.png и mydog.gif — meghatározott tartalomtípusú források).

Természetesen, ha saját webszervert írunk, érdemes egy adatbázist használni, hogy a perzisztens azonosítókat a jelenlegi formájukhoz kössük, bár óvakodjunk az adatbázisok korlátlan növekedésétől.

The Board of Shame – 1. sztori: 7. csatorna

1999-ben az oldalon nyomon követtem a hó miatti iskolabezárásokat http://www.whdh.com/stormforce/closings.shtml. Ne várja meg, amíg az információ megjelenik a TV képernyőjének alján! A kezdőlapomról linkeltem. Megérkezik az első 2000-es nagy hóvihar és megnézem az oldalt. Oda van írva:,

- Az állás szerint.
Jelenleg semmi sincs lezárva. Időjárási figyelmeztetés esetén kérjük, térjen vissza.

Nem lehet ilyen erős vihar. Vicces, hogy hiányzik a dátum. De ha az oldal főoldalára lép, ott lesz egy nagy „Bezárt iskolák” gomb, amely az oldalra vezet. http://www.whdh.com/stormforce/ a bezárt iskolák hosszú listájával.

Lehet, hogy megváltoztatták a lista lekérésének rendszerét – de nem kellett megváltoztatniuk az URI-t.

Board of Shame – 2. sztori: Microsoft Netmeeting

Az internettől való növekvő függőség következtében jött egy okos ötlet, hogy a gyártó weboldalára mutató hivatkozásokat alkalmazásokba is be lehetne ágyazni. Sokszor használták és visszaéltek vele, de az URL-t nem tudod megváltoztatni. Épp a minap próbálkoztam a Microsoft Netmeeting 2/something kliens linkjével a Help/Microsoft on the Web/Free dolgok menüben, és 404-es hibaüzenetet kaptam – a szerver nem kapott választ. Lehet, hogy már kijavították...

© 1998 Tim BL

Történelmi megjegyzés: A 20. század végén, amikor ezt írták, a "menő" a jóváhagyás jelzője volt, különösen a fiatalok körében, jelezve a divatosságot, a minőséget vagy a megfelelőséget. A sietség miatt az URI-útvonalat gyakran a "hűvösség" miatt választották a hasznosság vagy a tartósság helyett. Ez a bejegyzés megpróbálja átirányítani az energiát a menő keresése mögött.

Forrás: will.com