Författare — Sir Tim Berners-Lee, uppfinnaren av URI, URL, HTTP, HTML och World Wide Web, samt nuvarande ledare för W3C. Artikeln skrevs 1998.

Vilken URI kan anses vara "cool"?
En som inte förändras.
Hur förändras URI?
URI förändras inte; det är människor som förändrar dem.

Teoretiskt har människor ingen anledning att förändra URI (eller sluta stödja dokument), men i praktiken finns det miljontals.

Teoretiskt sett äger den nominella ägaren av domännamnsutrymmet faktiskt domännamnstomten och därmed alla URI i den. Bortsett från konkurs finns det inget som hindrar ägaren av domännamnet från att behålla det namnet. Och teoretiskt är URI-utrymmet under ditt domännamn helt under din kontroll, så att du kan göra det så stabilt som du vill. I stor utsträckning är den enda giltiga anledningen till att ett dokument försvinner från internet att företaget som ägde domännamnet gick i konkurs eller inte längre kan stödja driften av servern. Så varför finns det så många döda länkar i världen? Delvis beror det helt enkelt på bristande förutseende. Här är några anledningar som man kan höra:

Vi har bara omorganiserat webbplatsen för att göra den bättre.

Tycker du verkligen att gamla URI inte längre kan fungera? Om så är fallet har du valt dem väldigt dåligt. Tänk på att de nya ska bevaras efter nästa redesign.

Vi har så mycket material att vi inte kan följa upp vad som är föråldrat, vad som är konfidentiellt och vad som fortfarande är aktuellt, så vi tänkte att det är bättre att bara stänga ner allt.

Jag kan bara beklaga. W3C har gått igenom en period där vi var tvungna att noggrant gallra igenom arkivmaterial för integritet innan vi gjorde det offentligt. Beslutet måste vara genomtänkt på förhand — se till att du registrerar en acceptabel krets av läsare, skapelsedatum och, helst, sista datum för giltighet med varje dokument. Spara dessa metadata.

Nåväl, vi upptäckte att vi behöver flytta filerna...

Detta är en av de mest patetiska ursäkterna. Många vet inte att webbservrar låter dig hantera kopplingen mellan URI:n för objektet och dess faktiska plats i filsystemet. Tänk på URI-utrymmet som ett abstrakt utrymme, perfekt organiserat. Gör sedan en avbildning till vilken verklighet du faktiskt använder för att genomföra det. Informera sedan webbservern om detta. Du kan till och med skriva en del av din server för att få allt rätt.

John stöder inte den här filen längre, det gör Jane nu.

Var Johns namn i URI:n? Nej, bara filen låg i hans katalog? Jaha.

Tidigare använde vi ett CGI-skript för detta, nu använder vi ett binärt program.

Det finns en galen idé att sidor som skapats av skript ska ligga i "cgibin" eller "cgi"-området. Detta avslöjar hur du kör din webbserver. Byter du mekanik (även om du behåller innehållet), och plötsligt — alla dina URI:er ändras.

Låt oss ta National Science Foundation (NSF) som exempel:

NSF:s online-dokument

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

Den första sidan för att börja bläddra i dokument kommer uppenbarligen inte att förbli densamma om några år. cgi-bin, oldbrowse och pl — allt detta ger fragment av information om hur-vi-gör-det-nu. Om du använder en sida för att söka efter ett dokument får du lika dåligt resultat först:

Rapport från arbetsgruppen för kryptografi och kodteori

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

för dokumentets indexsida, även om själva html-dokumentet ser mycket bättre ut:

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

Här kommer rubriken pubs/1998 att ge alla framtida arkivtjänster en bra ledtråd för att förstå att det gamla klassificeringssystemet för dokument från 1998 är i bruk. Även om dokumentnummer i 2098 kan se annorlunda ut, kan jag föreställa mig att denna URI fortfarande kommer att vara giltig, och den kommer inte att störa NSF eller någon annan organisation som upprätthåller arkivet.

Jag trodde inte att URL:er måste vara permanenta — det har ju funnits URN.

Detta är förmodligen en av de sämsta bieffekterna av diskussionen om URN. Vissa tror att på grund av forskningen om ett mer permanent namnutrymme kan de vara slarviga med trasiga länkar eftersom "URN kommer att fixa allt detta". Om du är en av dessa personer, låt mig göra dig besviken.

De flesta URN-scheman jag har sett ser ut som en myndighetsidentifierare, följd av antingen ett datum och en sträng som du väljer, eller bara en sträng som du väljer. Det liknar väldigt mycket en HTTP URI. Med andra ord, om du tror att din organisation kommer att kunna skapa långlivade URN, bevisa det nu genom att använda dem för dina HTTP URI:er. I själva HTTP finns det inget som gör din URI instabil. Endast din organisation. Skapa en databas som kopplar URN-dokument till det aktuella filnamnet och låt webbservern använda den för att faktiskt hämta filer.

Om du har kommit så här långt, och om du inte har tid, pengar eller kontakter för att utveckla någon programvara, kan du ange följande ursäkt:

Vi ville, men vi har helt enkelt inte rätt verktyg.

Detta kan man känna medlidande för. Jag håller helt med. Det du behöver göra är att få webbservern att omedelbart hantera den beständiga URI:n och returnera filen, oavsett var den för närvarande lagras i ditt nuvarande galna filsystem. Du vill lagra alla URI:er i en fil som en kontroll och kontinuerligt hålla databasen aktuell. Du vill behålla relationer mellan olika versioner och översättningar av samma dokument, samt ha en oberoende post av kontrollsumman för att säkerställa skydd mot filskada genom mänskligt misstag. Och webbservrar levereras bara inte med dessa funktioner direkt ur lådan. När du vill skapa ett nytt dokument ber din redaktör om att ange en URI.

Du behöver möjlighet att ändra ägarskap, åtkomst till dokumentet, arkivnivåns säkerhetsnivå och mer i URI-rymd utan att ändra URI:n.

Allt är för illa. Men vi ska åtgärda det. På W3C använder vi funktionen Jigedit (Jigsaw-server för redigering), som spårar versioner, och vi experimenterar med dokumentgenereringsskripter. Om du utvecklar verktyg, servrar och klienter, håll denna fråga i åtanke!

Denna ursäkt gäller också många sidor på W3C, inklusive denna: så gör det jag säger, inte det jag gör.

Varför skulle det här bry mig?

När du ändrar URI på din server kan du aldrig helt säkerställa vem som har länkar till den gamla URI: n. Det kan vara länkar från vanliga webbsidor. Bokmärken till din sida. URI: n kan ha blivit skriven på kantexen av ett brev till en vän.

När någon klickar på en länk och den är trasig förlorar de vanligtvis förtroendet för serverägaren. Den personen blir också besviken — både emotionellt och verkligt, när de inte kan nå sitt mål.

Många människor klagar ständigt på döda länkar, och jag hoppas att skadan är uppenbar. Jag hoppas också att den reputationsskada som inträffar för serverunderhållaren, där dokumentet har försvunnit, är uppenbar.

Så vad ska jag göra? Designa URI

Det är webmasterens plikt att skapa URIer som kan användas om 2 år, om 20 år, om 200 år. Det kräver eftertanke, organisation och beslutsamhet.

URI: er förändras när någon information i dem förändras. Det är mycket viktigt hur du designar dem. (Vad, designa URI? Måste jag designa URI? Ja, du behöver tänka på det). Design handlar i grunden om att undvika att ha någon information i URI: n.

Dokumentets skapelsedatum — datumet då URI utfärdades — är något som aldrig kommer att förändras. Det är mycket användbart för att särskilja förfrågningar som använder det nya systemet från de som använder det gamla systemet. Det är en bra början för URI: n. Om dokumentet har ett datum angivet, även om dokumentet kommer att vara aktuellt i framtiden, så är det en bra början.

Det enda undantaget är en sida som avsiktligt är den 'senaste' versionen, till exempel för hela organisationen eller en stor del av den.

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

Detta är den sista spalten i Money Daily i tidskriften Money. Huvudorsaken till varför detta URI inte behöver ett datum är att det inte finns några anledningar att spara ett URI som kommer att överleva tidskriften. Begreppet Money Daily kommer att försvinna när Money försvinner. Om du vill referera till innehållet bör du hänvisa till det separat i arkiven:

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

(Ser bra ut. Antyder att "money" kommer att betyda samma sak under hela pathfinder.com:s existens. Det finns duplicering av "98" och onödigt ".html", men annars ser det ut som en stark URI.

Vad man ska lämna utanför

Allt! Förutom skapelsedatum, genom att sätta någon information i URI: n ber du i själva verket om problem.

• Författarens namn. Författarskap kan ändras med nya versioner. Folk lämnar organisationer och överlämnar saker till andra.
• Ämne. Det är väldigt komplicerat. Det ser alltid bra ut i början, men förändras otroligt snabbt. Jag kommer att berätta mer om detta nedan.
• Status. Kataloger som "gammal", "utkast" och så vidare, för att inte tala om "senast" och "cool", dyker upp i alla filsystem. Dokument ändrar status — annars skulle det inte finnas någon mening med att skapa utkast. Den senaste versionen av ett dokument behöver en konstant identifierare, oavsett dess status. Håll status utanför namnet.
• Åtkomst. På W3C har vi delat upp webbplatsen i sektioner för anställda, medlemmar och allmänheten. Det låter bra, men självklart börjar dokument som medarbetarnas teamidéer, diskuteras med medlemmar, och blir sedan offentliga. Det är faktiskt frustrerande om länkar till ett dokument bryts varje gång det öppnas för bredare diskussion! Nu går vi vidare till en enkel datumkod.
• Filändelse. Mycket vanligt. "cgi", även ".html" kommer att förändras i framtiden. Kanske om 20 år kommer ni inte att använda HTML för den här sidan, men dagens länkar till den måste fortfarande fungera. Kanoniska länkar på W3C:s webbplats använder inte filändelsen (hur detta görs).
• Programmekanismer. I URI letar du efter "cgi", "exec" och andra termer som ropar "titta på vilken programvara vi använder". Vill någon ägna hela sitt liv åt Perl CGI-skript? Nej? Då tar du bort filändelsen .pl. Läs serverguiden om hur man gör det.
• Disknamn. Kom igen! Men jag har sett sådana.

Så det bästa exemplet från vår webbplats är helt enkelt

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

… rapport om protokollet från W3C:s ordförandemöten.

Ämnen och klassificering enligt ämnen

Jag kommer att gå in mer i detalj om denna risk, eftersom det är en av de saker som är svårast att undvika. Som regel hamnar ämnen i URI när du klassificerar dina dokument efter det arbete som utförs. Men denna uppdelning kommer att förändras över tid. Namnen på områdena kommer att förändras. På W3C ville vi ändra MarkUP till Markup, och sedan till HTML, för att återspegla innehållet i sektionen. Dessutom finns det ofta ett platt namnrum här. Om 100 år kommer du säkerligen inte vilja återanvända något? Under vår korta livstid har vi redan velat återanvända "Historier" och "Stilmallar", till exempel.

Detta är ett lockande sätt att organisera en webbplats – och faktiskt ett mycket lockande sätt att organisera vad som helst, inklusive hela nätet. Det är en utmärkt lösning på medellång sikt men har allvarliga nackdelar på lång sikt.

Delvis beror orsakerna på filosofin kring betydelse. Varje term i språket är en potentiell klustringsobjekt, och varje person kan ha en annan uppfattning om vad den betyder. Eftersom relationerna mellan subjekten liknar en spindelväv snarare än ett träd, kan även de som enas om spindelväven välja en annan representation av trädet. Detta är mina (ofta upprepade) allmänna observationer kring farorna med hierarkisk klassificering som en generell lösning.

Faktum är att när du använder ett ämnesnamn i URI, binder du dig till en viss klassificering. Du kanske föredrar en annan variant i framtiden. Då kommer URI att vara utsatt för brott.

Anledningen till att använda ämnesområdet som en del av URI är att ansvaret för sektionerna i URI-rymden vanligtvis delegeras, och då behöver du namnet på den organisatoriska enheten – en avdelning, grupp eller något annat som bär ansvar för detta underområde. Det är en bindning av URI till den organisatoriska strukturen. Denna är vanligtvis säker endast när det längre (till vänster) URI skyddas av ett datum: 1998/pics kan betyda för din server "det vi menade 1998 under pics", snarare än "det vi gjorde 1998 med det vi nu kallar pics".

Glöm inte domännamnet

Kom ihåg att detta gäller inte bara sökvägen i URI, utan även servernamnet. Om du har separata servrar för olika saker, kom ihåg att denna uppdelning inte kan ändras utan att förstöra många, många länkar. Några klassiska misstag som "titta på vilken programvara vi använder idag" – domännamnen "cgi.pathfinder.com", "secure", "lists.w3.org" är skapade för att underlätta serveradministration. Oavsett om domänen representerar en viss avdelning i ditt företag, dokumentstatus, åtkomsträtt eller säkerhetsnivå, var mycket, mycket försiktig innan du använder mer än ett domännamn för flera typer av dokument. Kom ihåg att du kan dölja många webbservrar bakom en synlig webbserver med hjälp av omdirigering och proxying.

Ja, och tänk också på ditt domännamn. Du vill väl inte att folk ska referera till dig som soap.com efter att du bytt produktlinje och slutat producera tvål (Jag ber om ursäkt till den som äger soap.com just nu).

Slutsats

Att behålla URI:er i 2, 20, 200 eller till och med 2000 år är uppenbarligen inte så enkelt som det verkar. Ändå fattar webbansvariga beslut på internet som verkligen försvårar denna uppgift i framtiden. Det händer ofta eftersom de använder verktyg vars syfte är att presentera den bästa webbplatsen just nu – och ingen har bedömt vad som kommer att hända med länkarna när allt förändras. Men poängen här är att mycket, mycket kan förändras, och dina URI:er kan och bör förbli desamma. Det är bara möjligt när du tänker på hur du skapar dem.

Se även:

• Jakob Nielsens tirad om samma ämne

Tillägg

Hur man tar bort filändelser...

...från URI på den aktuella webbservern baserat på filer?

Om du till exempel använder Apache kan du konfigurera det för att matcha innehåll. Behåll filändelsen (till exempel .png) i filen (till exempel, mydog.png), men det går även att hänvisa till webbresursen utan det. Sedan kontrollerar Apache mappen för alla filer med det namnet och vilken tillägg som helst, och kan även välja den bästa av uppsättningen (till exempel GIF och PNG). Och det är inte nödvändigt att placera olika filtyper i olika kataloger, faktiskt kommer innehållsöverensstämmelse inte att fungera om du gör det.

• Konfigurera din server för innehållsöverensstämmelse
• Se alltid till att länkar refererar till URI utan tillägg

Länkar med tillägg kommer fortfarande att fungera, men tillåter inte din server att välja den bästa av de tillgängliga nuvarande och framtida formaten.

(Faktiskt, mydog, mydog.png och mydog.gif — giltiga webbresurser, mydog — är resurser av universell innehållstyp, och mydog.png och mydog.gif — resurser av specifik innehållstyp).

Självklart, om du skriver din egen webbserver, är det bra att använda en databas för att koppla permanenta identifierare till deras nuvarande form, även om du bör vara försiktig med obegränsad tillväxt av databasen.

Skamlistan — Historia 1: Channel 7

Under 1999 följde jag stängningen av skolor på grund av snö via sidan http://www.whdh.com/stormforce/closings.shtml. Ska man verkligen vänta på att informationen ska dyka upp längst ner på tv-skärmen? Jag lade en länk till den från min hemsida. Den första stora snöstormen 2000 inträffar och jag kontrollerar sidan. Det står:

— Vid status.
För närvarande är ingenting stängt. Vänligen återkom vid vädervarningar.

Kan inte vara, en så stark storm. Roligt nog saknas datumet. Men om du går till startsidan så finns det en stor knapp "Stängda skolor" som leder till sidan http://www.whdh.com/stormforce/ med en lång lista över stängda skolor.

Kanske de har ändrat systemet för att få listan — men de behövde inte ändra URI.

Skamlistan — Historia 2: Microsoft Netmeeting

Med den växande beroendet av internet kom den kloka idén att man kunde införa länkar till tillverkarens webbplats i applikationer. Detta användes ofta och missbrukades kraftigt, men — man kan inte ändra URL. Bokstavligt talat för några dagar sedan provade jag en länk från Microsoft Netmeeting 2/something i menyn Hjälp/Microsoft på webben/Gratis grejer, jag fick ett fel 404 — inget svar från servern. Kanske har de redan lagat det…

©1998 Tim BL

Historisk anmärkning: i slutet av 1900-talet, när detta skrevs, var "cool" ett epitet av godkännande, särskilt bland ungdomar, som pekade på trendighet, kvalitet eller lämplighet. I brådska valdes URI-vägen ofta för dess "coolhet" snarare än dess användbarhet eller hållbarhet. Denna notering är ett försök att omdirigera energin bakom sökandet efter coolhet.

Källa: habr.com