Vzhledem k tomu, že pokud vím, web design se u nás zatím soustavně nevyučuje, zůstávají jedinými odpovědnými za svou odbornost sami web designeři a autoři různých příruček pro webmastery. Ne každý měl asi v knihkupectví takové štěstí, že natrefil na Satrapův Web Design (Satrapa, Pavel: Web Design. Neokortex, Praha, 1997, ISBN 80–902230–1-X), kde autor za URL ztratil slovo. S dotazem k adresářové stavbě webserveru a cestám v URL se na mě v poslední době obrací stále více koderů, zvláště pokud mají připravit rozsáhlý informační system, u kterého se v budoucnu předpokládá růst. Musím říci, že kromě knihy Pavla Satrapy pro mě v tomto směru byla velmi důležitá škola, kterou mi poskytli líní, lhostejní a nespolupracující administrátoři, které jsem za těch pár let potkal.
Dokud nebudeme mít k dispozici funkční system URN, bude URL jedinou cestou, jak získávat informace z Internetu. O URN se hovoří jako o vyspělejší formě odkazování hlavně z toho důvodu, že umístění zdroje se mění, kdežto názvy nikoli. Pokud v případě měst dochází častěji ke změně názvu (srovnej město Zlín) než k změně umístění (srovnej město Most), pak v případě zdrojů na Internetu je tomu právě naopak. Určitě už se vám někdy stalo, že jste po čase zavítali na určitý FTP server a soubor, jenž jste hodlali získat, tu již nebyl (mohl být třeba přesunut do adresáře /pub/app/old).
Jeden z nejdůležitějších nároků na URL je její stálost. Správce internetových sídel by měl při návrhu struktury postupovat velmi rozvážně. Měl by například brát v úvahu budoucí vývoj, kdy je možné, že stávající drobná prezentace se rozroste v informační system olbřímích rozměrů. Webmaster by měl počítat s tím, že dokumenty budou zastarávat, měnit se, přibývat. URL by se zásadně neměla měnit, jenom protože se změnil vzhled sídla nebo server. Trochu problém je při přesunu souborů z jedné domény na druhou. Například když své sídlo z poskytovatel.cz/sidlo přesunete na sidlo.cz. Právě nespolupracující administrátoři mě donutili, abych se poohlédnul po nějakém řešení a světe, div se, ono existuje a je dokonce velmi snadné (a každému webhosterovi známé). V předvolbách webserveru se dá nastavit přesměrování, a to dokonce velmi chytré přesměrování založené na regulárních výrazech (viz Apache.org, mod_rewrite). Pokud už dojde k takovému přesunu, je žádoucí, aby na to byl uživatel upozorněn například tím, že se mu na několik sekund zobrazí stránka s informací o změně, a následně je přesměrován. K tomuto řešení potřebujete chybovou stránku a možnost zjistit volanou URL a její přestavění na novou URL podobně jako v předchozím případě.
Při redesignu jednoho statistického serveru mě zadavatel upozorňoval na to, že je celý postaven na technologii ASP a tabulkách XLS. Při bližším pohledu však vyšlo najevo, že server poskytuje obyčejné HTML a tabulky tu jsou jen ke stažení – přípony občas matou. Server jsme přepsali v PHP, ale původní přípony jsme zachovali. Při pohledu na URL serveru developer.netscape.com bych také nedal moc za to, že stránky s příponami HTM jsou ve skutečnosti vygenerované. Mnozí webmasteři ovšem o možnosti provést lokální změnu v nastavení obsluhy přípon netuší a administrátoři jim v tom nepomohou. Vrtá mi hlavou proč. Proč nemá koder-profesionál ambici vyzvědět něco o fungování webserveru? Proč se administrátoři serverů nenamáhají s klientem spolupracovat? Výsledek společného úsilí by přeci byl ku prospěchu všech (studio si nechá své úsilí zaplatit, webhoster může fakturovat práci administrátora).
Pro kvalifikaci webmastera je nepostradatelná znalost různých operačních systemů. Například ze Apple MacOS jsem zvyklý, že názvy nemohou být moc dlouhé, z Windows vím, že nezáleží na velikosti písmen a v unixu mě nepřekvapuje absence automatického rozpoznání datového formátu souboru. Jako webmaster tedy budu navrhovat strukturu website tak, aby nekolidovala s žádným z možných webserverů, na kterých možná někdy poběží. Přesto už jsem se nejednou v URL setkal nejen s ignorací problému OS, ale dokonce s nerespektováním RFC 1738 (zvláště co se dovolených znaků týče).
Dalším požadavkem na URL je možnost snadného zapamatování nebo alespoň reprodukce. Ruští kolegové dokonce v této souvislosti protestují proti kombinování ruštiny a angličtiny (jak v cestě jako takové, tak i v každém názvu jednotlivě). V případě ruských kolegů se k tomuto doporučení také přikláním: pro mě je už tak dost matoucí transkripce ruštiny do latinky. Pro potřeby českých serverů a českých uživatelů snad postačí, když řeknu, že URL by se měla pokud možno skládat ze slov, že by neměla obsahovat neobvyklé znaky a neprůhledné shluky znaků. Reprodukovatelnost URL vzala zasvé zvláště v poslední době, kdy je každý druhý server napsaný v nějakém serverovém skriptu. Je sice výborné, že dokážete každý typ obsahu vyvolat pomocí jediného skriptu s patřičnými proměnnými, ale věřte, že pro člověka, který si chce adresu opsat, je statická prezentace mnohdy zajímavější. Zajímavé řešení tohoto problému mně ukázal Jakub Chromý u projektu miesto.sk, kde obsahu dosahujete pouze pomocí řady adresářů, soubory jsou pak inicializační. Tímto řešením se vyhnete problému s přechodem na jiný server s jinými příponami nebo technologiemi – URL tu totiž nic nevypovídá o způsobu sestavování obsahu dokumentu, ale o jeho začlenění do obsahové stuktury. Domnívám se, že kdyby podobný postup zvolili ti, kdož nechávají čtenáře ke všem stránkám serveru přistupovat pomocí souboru /go.asp, čtenáři by to náležitě ocenili (třeba snížením náporu na fulltextový vyhledavač). Navíc myslím, že by neměl být problém říci webserveru, že cesta oddělovaná lomítky nesměřuje k adresářům, ale že mezi lomítky se nacházejí promenna_hodnota (~ s///&/g; ~ s/_/=/g;).
A posledním, ne však zanedbatelným nárokem na URL podle mého gusta je její schopnost vypovídat o obsahové struktuře sídla – tato vlastnost se v odborné literatuře pojmenovává jako navigovatelnost (navigability). Znamená to, že pokud odmažeme jakýkoli počet celků (názvů souborů a adresářů) od konce, vždy se dostaneme na stránku umístěnou v obsahové hierarchii výše. Pro správce internetového sídla to pak znamná imperativ v každé složce ustanovit inicializační dokument.
Není to mnoho, co po tvůrcích URL požaduji: stálost, srozumitelnost a navigovatelnost. Mohl bych také chtít, aby URL nebylo delší než 1024 znaků (aby nepůsobilo problémy s browsery), než 255 znaků (aby se dalo zanést do VarChar v databázi), než 160 znaků (aby se mohlo odeslat přes SMS) nebo než 76 (aby se nelámalo při posílání v e-mailu). Mohl bych chtít, aby názvy souborů a adresářů nebyly zbytečně dlouhé (trable_s_nejnezprostredkovavatelnejsimi_ zazitky_z_dovolene_na_jezere_titikaka.html) a podobně. Ale opravdu mi postačí jen ty tři vlastnosti.
Pokud se nebojíte azbuky, doporučuji vaší pozornosti článek : design.ru.
