A szerző — Tim Berners-Lee, az URI, URL, HTTP, HTML és a Világháló feltalálója, a W3C jelenlegi vezetője. A cikk 1998-ban készült.

Milyen URI számít "menőnek"?
Olyan, ami nem változik.
Hogyan változnak a URI-k?
A URI-k nem változnak: az emberek változtatják meg azokat.

Elvileg az embereknek nincs okuk megváltoztatni a URI-kat (vagy leállítani a dokumentumok karbantartását), de a gyakorlatban ez több millió esetet is felölel.

Elméletileg a domain név térének névleges tulajdonosa valóban birtokolja a domain név területét, és így minden URI-t is, ami oda tartozik. Fizetésképtelenségen kívül semmi sem akadályozza meg a domain név tulajdonosát abban, hogy megtartsa ezt a nevet. Elméletben a URI-k területe a te domain neved alatt teljes mértékben a te irányításod alatt áll, így olyan stabilra formálhatod, amennyire csak szeretnéd. Nagyjából az egyetlen hiteles ok a dokumentum eltűnésére az interneten az, hogy a domain nevet birtokló cég csődbe ment, vagy már nem tudja fenntartani a szerver működését. Akkor miért van annyi eltűnt link a világban? Részben ez egyszerű előrelátás hiánya. Íme néhány érv, amit gyakran hallani lehet:

Csak átszerveztük a weboldalt, hogy jobbá tegyük.

Tényleg úgy gondolod, hogy a régi URI-k már nem működhetnek? Ha így van, akkor nagyon rosszul választottad őket. Gondolj arra, hogy a újak megmaradjanak a következő újratervezés után.

Annyi anyagunk van, hogy nem tudjuk nyomon követni, mi elavult, mi bizalmas, és mi még aktuális, ezért úgy gondoltuk, hogy jobb mindent letiltani.

Csak sajnálni tudom. A W3C átélt egy időszakot, amikor gondosan át kellett néznünk az archív anyagokat a bizalmasság érdekében, mielőtt nyilvánosságra hoztuk volna őket. A döntést előre meg kell tervezni — győződj meg róla, hogy minden dokumentummal megfelelő olvasói kört, létrehozási dátumot és lehetőleg lejárati időt rögzítesz. Tartsd meg ezeket a metadatákat.

Nos, kiderült, hogy a fájlokat át kell helyeznünk...

Ez az egyik legszánalmasabb kifogás. Sokan nem tudják, hogy a webszerverek lehetővé teszik a kapcsolat kezelését az objektum URI-ja és annak tényleges helye között a fájlrendszerben. Képzelje el az URI teret, mint egy absztrakt teret, amely tökéletesen van megszervezve. Ezután készítsen egy leképezést bármilyen valóságra, amelyet ténylegesen használ a megvalósításhoz. Majd értesítse erről a webszervert. Még egy saját szerverdarabot is írhat, hogy mindent helyesen tegyen meg.

John már nem támogatja ezt a fájlt, most Jane teszi.

John neve szerepelt az URI-ban? Nem, csak a fájl volt a könyvtárában? Nos, értem.

Korábban CGI-szkriptet használtunk erre, most pedig bináris programot használunk.

Van egy őrült ötlet, hogy a szkriptek által létrehozott oldalaknak a "cgibin" vagy "cgi" területen kell elhelyezkedniük. Ez felfedi, hogyan indítja el a webszerverét. Megváltoztatja a mechanizmust (még a tartalom megőrzése mellett), és hopp — az összes URI-ja megváltozik.

Vegyük például a Nemzeti Tudományos Alapítványt (NSF):

NSF online dokumentumok

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

Az első oldal, hogy elkezdjük megnézni a dokumentumokat, nyilvánvalóan pár év múlva már nem marad ilyen. cgi-bin, oldbrowse és pl — mindez információt ad arról, hogyan csináljuk ezt most. Ha egy oldalt használ, hogy dokumentumot keressen, akkor ugyanolyan rossz eredményt kap először:

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 a html-dokumentum sokkal jobban néz ki:

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

Itt a pubs/1998 cím bármilyen jövőbeli archív szolgáltatásnak jó kulcsot ad a megértéshez, hogy miért működik a régi dokumentumkategorizálási séma 1998 óta. Bár 2098-ban a dokumentumok számai másképp nézhetnek ki, elképzelhetem, hogy ez az URI még mindig érvényes lesz, és semmilyen problémát nem okoz a NSF-nek vagy bármely más szervezetnek, amely támogatja az archívumot.

Nem gondoltam, hogy az URL-címeknek állandónak kell lenniük — voltak URN-ek is.

Valószínűleg ez az egyik legrosszabb mellékhatása az URN-ről folytatott vitának. Egyesek azt gondolják, hogy a tartós névterek kutatásainak eredményeként hanyagul kezelhetik a lógó hivatkozásokat, mert „az URN mindent megold.” Ha Ön is ezek közé az emberek közé tartozik, engedje meg, hogy kiábrándítson.

A legtöbb URN séma, amit láttam, olyan autoritásazonosítóként működik, amelyet vagy egy kiválasztott dátum és szöveg, vagy csak egy kiválasztott szöveg követ. Ez nagyon hasonlít a HTTP URI-ra. Más szavakkal, ha úgy gondolja, hogy a szervezete képes lesz hosszú életű URN-eket létrehozni, akkor ezt most bizonyítsa be, használva őket a HTTP URI-jához. A HTTP-n belül nincs semmi, ami a URI-ját instabillá tenné. Csak a szervezete. Hozzon létre egy adatbázist, amely összekapcsolja a dokumentum URN-jét a jelenlegi fájlnevével, és engedje meg a webszervernek, hogy ezt használja a fájlok tényleges kiolvasásához.

Ha eddig eljutott, és nincs ideje, pénze és kapcsolata, hogy kifejlesszen valamilyen szoftvert, akkor a következő kifogást teheti:

Szerettük volna, de egyszerűen nincsenek meg a szükséges eszközeink.

Ezért sajnálatot lehet érezni. Teljesen egyetértek. Amit tennie kell, az az, hogy a webszerver azonnal feldolgozzon egy állandó URI-t, és visszaadja a fájlt, bárhol is tárolják azt éppen a jelenlegi őrült fájlrendszerében. Azt szeretné, ha az összes URI fájlban lenne tárolva ellenőrzésként, és folyamatosan naprakészen tartaná az adatbázist. Szüksége van a különböző verziók és fordítások közötti kapcsolatok megőrzésére, valamint független ellenőrző összeg nyilvántartására, hogy megvédje a fájlokat a véletlen hibák által okozott megsérüléstől. És a webszerverek nem jönnek ezekkel a funkciókkal dobozból. Amikor új dokumentumot szeretne létrehozni, a szerkesztője arra kéri, hogy adjon meg egy URI-t.

Olyan képességre van szüksége, hogy módosítsa a tulajdonjogot, a dokumentumhoz való hozzáférést, az archív szintű biztonsági szintet és egyebeket az URI térben anélkül, hogy megváltoztatná az URI-t.

Túl rossz. De helyre fogjuk hozni. A W3C-nél a Jigedit funkciót (Jigsaw szerver az adatlapok szerkesztéséhez) használjuk, amely nyomon követi a verziókat, és dokumentumkészítő szkriptekkel kísérletezünk. Ha Ön eszközöket, szervereket és klienseket fejleszt, figyeljen erre a problémára!

Ez a kifogás számos W3C oldalra is vonatkozik, beleértve ezt is: tehát csinálja azt, amit mondok, ne azt, amit teszek.

Miért kellene ez engem érdekelnie?

Amikor megváltoztatja a URI-t a szerverén, soha nem tudhatja pontosan, hogy ki hivatkozik a régi URI-re. Ezek lehetnek linkek normál weboldalakról. Könyvjelzők az Ön oldalára. A URI lehet, hogy egy barátnak írt levél margójára volt feljegyezve.

Amikor valaki rákattint egy linkre, és az törött, általában elveszíti a bizalmát a szerver tulajdonosában. Emellett csalódott is — érzelmileg és ténylegesen is, mert nem tudja elérni a célját.

Sokan folyamatosan panaszkodnak a törött linkekre, és remélem, hogy a kár nyilvánvaló. Remélem, hogy a szerver karbantartójának a hírnevében okozott kár is egyértelmű.

Mit tegyek? URI tervezés.

A webmaster kötelessége, hogy olyan URI-kat alakítson ki, amelyeket 2 év múlva, 20 év múlva vagy akár 200 év múlva is használni lehet. Ehhez megfontoltság, szervezettség és céltudatosság szükséges.

A URI-k megváltoznak, ha bennük információ változik. Nagyon fontos, hogyan tervezi őket. (Mi, URI tervezés? URI-t kell terveznem? Igen, érdemes rajta elgondolkodni). A tervezés alapvetően azt jelenti, hogy semmilyen információ nincs a URI-ban.

A dokumentum létrehozásának dátuma — a URI kiadási dátuma — az, ami soha nem változik. Ez nagyon hasznos a kérések szétválasztására, amelyek az új rendszert használják, valamint azok számára, akik a régi rendszert használják. Ezzel érdemes kezdeni a URI-t. Ha a dokumentumon van valamilyen dátum, még ha a dokumentum a jövőben aktuális is lesz, ez egy jó kezdet.

Az egyetlen kivétel az az oldal, amely szándékosan a „legutolsó” változat, például egy egész szervezet vagy annak nagy része számára.

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

Ez a Money Daily utolsó oszlopa a Money folyóiratban. Az alapvető oka annak, hogy ebben a URI-ban nincs szükség dátumra, hogy nincs ok arra, hogy megőrizzük a URI-t, amely túléli a folyóiratot. A Money Daily fogalma akkor tűnik el, amikor a Money eltűnik. Ha tartalomra szeretne hivatkozni, azt külön kell hivatkozni az archívumban:

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

(Jónak tűnik. Azt sugallja, hogy a "money" azonos jelentéssel bír az egész pathfinder.com létezése alatt. Vannak "98" ismétlődései és felesleges ".html", de egyébként erős URI-nak tűnik.

Mit hagyjunk figyelmen kívül.

Mindent! A létrehozási dátum kivételével, bármilyen információt a URI-be helyezve, akaratlanul is problémákat szalajt.

A szerző neve. A szerződés a újabb verziók megjelenésével változhat. Az emberek távoznak a szervezetekből, és átadják a feladatokat másoknak.
Tárgy. Ez nagyon bonyolult. Eleinte mindig jól néz ki, de meglepően gyorsan megváltozik. Részletesebben mesélek róla később.
Státusz. Az olyan mappák, mint a „régi”, a „vázlat” és így tovább, nem is beszélve a „legutóbbi” és a „nagyszerű” státuszokról, minden fájlrendszerben megjelennek. A dokumentumok státuszt váltanak – különben nem lenne értelme a vázlatok létrehozásának. A dokumentum legújabb verziójának állandó azonosítóra van szüksége, függetlenül a státuszától. Tartsuk távol a státuszt a névtől.
Hozzáférés. A W3C-nél a webhelyet szakaszokra osztottuk az alkalmazottak, a tagok és a nyilvánosság számára. Jól hangzik, de nyilvánvalóan a dokumentumok csapatjavaslatként kezdődnek, tagokkal beszélgetnek, majd a nyilvánosság előtt is elérhetők lesznek. Valóban sértő, ha minden alkalommal, amikor egy dokumentumot szélesebb körű vitára nyitunk meg, az összes régi hivatkozás törötté válik! Most áttérünk egy egyszerű dátumkódra.
Fájlkiterjesztés. Nagyon elterjedt jelenség. A „cgi”, még a „.html” is meg fog változni a jövőben. Lehet, hogy 20 év múlva már nem HTML-t használsz majd ennek az oldalnak a megjelenítésére, de a mai hivatkozásoknak továbbra is működniük kell. A W3C webhelyén a kanonikus hivatkozások nem használják a kiterjesztést (hogyan működik).
Programozási mechanizmusok. Az URI-ban keresd a „cgi”, „exec” és más kifejezéseket, amelyek azt kiáltják: „Nézd, milyen szoftvert használunk”. Valaki életét akarja szentelni a Perl CGI szkripteknek? Nem? Akkor távolítsd el a .pl kiterjesztést. Olvasd el a szerver útmutatóját, hogy megtudd, hogyan kell ezt megtenni.
Lemeznév. Ugyan már! De én már láttam ilyet.

Szóval a legjobb példa az oldalunkról egyszerűen

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

… a W3C elnökeinek üléséről készült jegyzőkönyvjelentés.

Témák és témák szerinti osztályozás

Részletesebben beszélek erről a veszélyről, mivel ez az egyik legnehezebben elkerülhető dolog. Általában a témák a URI-ba kerülnek, amikor a dokumentumait az elvégzett munka szerint osztályozza. De ez a felosztás idővel megváltozik. A területek nevei meg fognak változni. A W3C-nél meg akartuk változtatni a MarkUP-ot Markupra, majd HTML-ra, hogy tükrözze a rész tartalmát. Ezen kívül gyakran itt sík névtér van. 100 év múlva biztos vagy benne, hogy nem akarsz semmit újra felhasználni? Rövid életünk alatt már szeretnénk újra használni a „Történelem” és „Stíluslapok” például.

Ez csábító módja a weboldal szervezésének – és igazán csábító módja bárminek a szervezésére, beleértve az egész internetet is. Ez egy nagyszerű középtávú megoldás, de hosszú távon komoly hátrányai vannak.

Részben az okok a jelentés filozófiájában rejlenek. Minden kifejezés a nyelvben potenciális klaszterezési objektum, és minden embernek más elképzelése lehet arról, mit is jelent. Mivel a szubjektumok közötti kapcsolatok inkább hasonlítanak egy hálóra, mint egy fára, még azok is, akik egyetértenek a hálóval, választhatnak egy másik fát. Ezek az én (gyakran megismételt) általános megjegyzéseim a hierarchikus osztályozás veszélyeiről mint általános megoldásról.

Valójában, amikor egy téma nevét használja a URI-ban, akkor egyfajta osztályozáshoz köti magát. Lehetséges, hogy a jövőben egy másik lehetőséget fog választani. Akkor a URI megsérülhet.

Az ok, amiért a témakört a URI részeként használják, az az, hogy a URI területek alosztályaiért a felelősséget általában delegálják, és akkor szükség van egy szervezeti szerv nevére – részleg, csoport vagy bármi más, ami felelős ezért az aldomainért. Ez a URI kötődése a szervezeti struktúrához. Általában akkor biztonságos, amikor a URI bal oldalán dátummal van védve: 1998/pics jelentheti a szervered számára, hogy „amit 1998-ban a pics alatt értettünk”, nem pedig „amit 1998-ban csináltunk azzal, amit most pics-nek hívunk”.

Ne felejtsd el a domain nevet

Ne feledje, hogy ez nemcsak az URI útvonalára vonatkozik, hanem a szerver nevére is. Ha különböző dolgokhoz külön szerverei vannak, emlékezzen arra, hogy ezt a megosztást nem lehet megváltoztatni anélkül, hogy sok, sok linket el ne veszítene. Néhány klasszikus hiba, mint például „nézd, milyen szoftvert használunk ma” – domainnevek "cgi.pathfinder.com", "secure", "lists.w3.org". Ezeket azért hozták létre, hogy megkönnyítsék a szerverek adminisztrálását. Akár egy osztályt képvisel a domain a cégeden belül, akár a dokumentum státusza, hozzáférési szintje vagy biztonsági szintje, legyél nagyon, nagyon óvatos, mielőtt több domainnevet használnál különböző típusú dokumentumokhoz. Emlékezz arra, hogy számos webszervert elrejthetsz egyetlen látható webszerver mögött átirányítással és proxyzással.

Igen, és még gondolj a domainnevedre is. Nem akarod, hogy utána úgy hivatkozzanak rád, mint a soap.com, miután megváltoztatod a termékcsaládodat, és már nem gyártasz szappant (elnézést kérek aztól, aki jelenleg a soap.com birtokosa).

Zárás

A URI-k 2, 20, 200 vagy akár 2000 évig történő fenntartása nyilvánvalóan nem olyan egyszerű, mint amilyennek tűnik. Mindazonáltal az interneten a webmesterek olyan döntéseket hoznak, amelyek valójában megnehezítik számukra ennek a feladatnak a jövőbeni könnyű végrehajtását. Gyakran azért történik ez, mert olyan eszközöket használnak, amelyeknek az a feladata, hogy jelenleg a legjobb webhelyet mutassák be - és senki sem értékelte, mi fog történni a linkekkel, amikor minden megváltozik. Azonban a lényeg abban rejlik, hogy sok, nagyon sok minden megváltozhat, és a URI-jaidnak változatlanoknak kell maradniuk. Ez csak akkor lehetséges, ha figyelembe veszed, hogyan hozod létre őket.

Lásd még:

Jakob Nielsen tirádája ugyanezen a témán

Kiegészítések

Hogyan távolítsuk el a fájlkiterjesztéseket…

…az URI-ból a jelenlegi webszerveren fájlok alapján?

Ha például Apache-t használsz, akkor be tudod állítani, hogy a tartalom egyeztetése történjen. Megtartod a fájl kiterjesztését (például .png) a fájlban (például, mydog.png), de azonban hivatkozhatunk a webes erőforrásra nélküle is. Ezután az Apache ellenőrzi a könyvtárat, hogy léteznek-e olyan fájlok, melyek ennek a névnek bármely kiterjesztésével rendelkeznek, és ki tudja választani a legjobbat a készletből (például GIF és PNG). Nincs szükség különböző fájltípusok eltérő könyvtárakba helyezésére, a tartalom egyeztetése nem fog működni, ha ezt megteszed.

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

A kiterjesztéssel rendelkező hivatkozások továbbra is működni fognak, de nem engedik meg a szerverének, hogy kiválassza a jelenleg és a jövőben elérhető legjobb formátumot.

(Valójában, mydog, mydog.png és mydog.gif — érvényes webes erőforrások, mydog — ez egy univerzális tartalomtípus, míg mydog.png és mydog.gif — konkrét tartalomtípusokkal bíró erőforrások).

Természetesen, ha saját webkiszolgálót írsz, érdemes adatbázist használni a tartós azonosítók aktuális formájukhoz való kötésére, bár óvatosan kell eljárni a korlátlan adatbázis-növekedés elkerülése érdekében.

Gyámsági tábla — Történet 1: Channel 7

1999 során nyomon követtem az iskolák bezárását a hó miatt az oldalon. http://www.whdh.com/stormforce/closings.shtml. Nem várhatom, hogy az információ megjelenjen a tévé képernyőjének alján! Hivatkoztam rá a kezdőlapomról. Elérkezett 2000 első nagy hóvihara, és ellenőriztem az oldalt. Így szólt:

— Státusz.
Jelenleg semmi nincs bezárva. Kérjük, térjen vissza időjárás-előrejelzések esetén.

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

Lehet, hogy átalakították a lista beszerzési rendszerét — de nem kellett volna módosítani a URI-t.

Gyámsági tábla — Történet 2: Microsoft Netmeeting

Az internetre való növekvő függőséggel felmerült az ésszerű ötlet, hogy az alkalmazásokba hivatkozásokat lehet beépíteni a gyártó weboldalára. Ezt gyakran használták és erősen visszaéltek vele, de — nem lehet megváltoztatni az URL-t. Pár nappal ezelőtt megpróbáltam egy hivatkozást a Microsoft Netmeeting 2/something ügyfél Help/Microsoft on the Web/Free stuff menüjéből, és 404-es hibát kaptam — a szerver nem találta meg a választ. Lehet, hogy már megjavították...

Történeti megjegyzés: a 20. század végén, amikor ezt írták, a „menő” egy jóváhagyó jelző volt, különösen a fiatalok körében, a divatosságra, minőségre vagy relevanciára utalva. A sietségben az URI útvonalát gyakran a „menőség” alapján választották, nem pedig a hasznosság vagy tartósság miatt. Ez a megjegyzés megpróbálja átirányítani az energiát, amely a menőség keresése mögött áll.

Forrás: habr.com