Författare: Sir Tim Berners-Lee, uppfinnare av URI:er, URL:er, HTTP, HTML och World Wide Web, och nuvarande chef för W3C. Artikel skriven 1998

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

I teorin finns det ingen anledning för människor att ändra URI (eller sluta med stödjande dokument), men i praktiken finns det miljoner av dem.

I teorin äger den nominella ägaren av ett domännamnutrymme faktiskt domännamnområdet och därför alla URI:er inom det. Förutom insolvens hindrar ingenting ägaren av ett domännamn från att behålla namnet. Och i teorin är URI-utrymmet under ditt domännamn helt under din kontroll, så du kan göra det så stabilt som du vill. I stort sett den enda goda anledningen till att ett dokument försvinner från internet är att företaget som ägde domännamnet har gått i konkurs eller inte längre har råd att hålla servern igång. Varför finns det så många saknade länkar i världen? En del av detta är helt enkelt en brist på eftertanke. Här är några anledningar till att du kan höra:

Vi har just omorganiserat sidan för att göra den bättre.

Tror du verkligen att de gamla URI:erna inte kan fungera längre? Om så är fallet, valde du dem väldigt dåligt. Överväg att behålla de nya för nästa redesign.

Vi har så mycket grejer att vi inte kan hålla reda på vad som är inaktuellt, vad som är konfidentiellt och vad som fortfarande är relevant, så vi tänkte att det var bäst att bara stänga av allt.

Jag kan bara sympatisera. W3C gick igenom en period där vi var tvungna att noggrant sålla igenom arkivmaterial för konfidentialitet innan vi offentliggjorde dem. Beslutet bör vara genomtänkt i förväg - se till att du med varje dokument registrerar godtagbar läsekrets, skapandedatum och, helst, utgångsdatum. Spara denna metadata.

Tja, vi upptäckte att vi måste flytta filer...

Detta är en av de mest patetiska ursäkterna. Många vet inte att webbservrar låter dig kontrollera förhållandet mellan ett objekts URI och dess faktiska plats i filsystemet. Tänk på URI-utrymmet som ett abstrakt utrymme, perfekt organiserat. Gör sedan en kartläggning till vilken verklighet du än använder för att förverkliga den. Rapportera sedan detta till webbservern. Du kan till och med skriva ditt eget serverkodavsnitt för att få det rätt.

John underhåller inte längre den här filen, det gör Jane nu.

Fanns Johns namn i URI:n? Nej, fanns filen bara i hans katalog? Okej.

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

Det finns en galen idé att sidor skapade av skript ska vara placerade i "cgibin"- eller "cgi"-området. Detta avslöjar mekaniken i hur du kör din webbserver. Du ändrar mekanismen (även när du sparar innehåll), och oj - alla dina URI:er ändras.

Ta National Science Foundation (NSF) till exempel:

NSF onlinedokument

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

Den första sidan för att börja titta på dokument kommer helt klart inte att vara densamma om några år. cgi-bin, oldbrowse и pl - allt detta ger ut bitar av information om hur-vi-gör-det-nu. Om du använder sidan för att söka efter ett dokument är det första resultatet du får lika dåligt:

Rapport från arbetsgruppen för kryptologi och kodningsteori

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

för dokumentindexsidan, även om html-dokumentet i sig 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 god ledtråd om att det gamla dokumentklassificeringssystemet från 1998 är i kraft. Även om dokumentnumren kan se annorlunda ut under 2098, skulle jag föreställa mig att denna URI fortfarande skulle vara giltig och inte skulle störa NSF eller någon annan organisation som skulle underhålla arkivet.

Jag trodde inte att webbadresser behövde vara beständiga – det fanns URN:er.

Detta är förmodligen en av de värsta bieffekterna av URN-debatten. Vissa människor tror att på grund av forskningen om ett mer permanent namnutrymme, kan de vara slarviga med att dingla länkar eftersom "URN:er fixar allt det där." 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 auktoritetsidentifierare följt av antingen ett datum och en sträng du väljer, eller bara en sträng du väljer. Detta är mycket likt en HTTP URI. Med andra ord, om du tror att din organisation kommer att kunna skapa långlivade URN:er, bevisa det nu genom att använda dem för dina HTTP URI:er. Det finns inget i själva HTTP som gör din URI instabil. Bara din organisation. Skapa en databas som mappar dokumentets URN till det aktuella filnamnet och låt webbservern använda den för att faktiskt hämta filerna.

Om du har nått denna punkt, om du inte har tid, pengar och anslutningar för att utveckla någon mjukvara, kan du ange följande ursäkt:

Vi ville, men vi har helt enkelt inte de rätta verktygen.

Men du kan sympatisera med detta. Jag håller med fullständigt. Vad du behöver göra är att tvinga webbservern att omedelbart analysera den beständiga URI:n och returnera filen varhelst den för närvarande är lagrad i ditt nuvarande galna filsystem. Du vill lagra alla URI:er i en fil som en kontroll och hålla databasen uppdaterad hela tiden. Du vill bevara förhållandet mellan olika versioner och översättningar av samma dokument, och även upprätthålla en oberoende kontrollsummapost för att säkerställa att filen inte skadas av ett oavsiktligt fel. Och webbservrar kommer helt enkelt inte ur lådan med dessa funktioner. När du vill skapa ett nytt dokument ber din redaktör dig att ange en URI.

Du måste kunna ändra ägande, dokumentåtkomst, säkerhet på arkivnivå etc. i URI-utrymmet utan att ändra URI.

Det är för dåligt. Men vi kommer att rätta till situationen. På W3C använder vi funktionen Jigedit (Jigsaw editing server) som spårar versioner, och vi experimenterar med skript för att skapa dokument. Om du utvecklar verktyg, servrar och klienter, var uppmärksam på detta problem!

Denna ursäkt gäller även många W3C-sidor, inklusive den här: så gör som jag säger, inte som jag gör.

Varför skulle jag bry mig?

När du ändrar URI på din server kan du aldrig helt avgöra vem som kommer att ha länkar till den gamla URI:n. Dessa kan vara länkar från vanliga webbsidor. Bokmärk din sida. URI:n kan ha blivit nedklottrad i marginalen på ett brev till en vän.

När någon följer en länk och den bryts tappar de vanligtvis förtroendet för serverägaren. Han är också frustrerad, både känslomässigt och fysiskt, över att inte kunna nå sitt mål.

Många människor klagar på trasiga länkar hela tiden, och jag hoppas att skadan är uppenbar. Jag hoppas att anseendeskadan för underhållaren av servern där dokumentet försvann också är uppenbar.

Så vad skall jag göra? URI design

Det är webbmasterns ansvar att tilldela URI:er som kan användas om 2 år, om 20 år, om 200 år. Detta kräver omtanke, organisation och beslutsamhet.

URI:er ändras om någon information i dem ändras. Hur du designar dem är mycket viktigt. (Vad, URI-design? Behöver jag designa URI? Ja, det borde du tänka på). Design innebär i princip att man utelämnar all information i URI:n.

Datumet då dokumentet skapades - datumet då URI:n utfärdades - är något som aldrig kommer att ändras. Det är mycket användbart för att skilja frågor som använder det nya systemet från de som använder det gamla systemet. Det här är ett bra ställe att börja med en URI. Om en handling är daterad, även om handlingen kommer att vara aktuell i framtiden, så är detta 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 senaste Money Daily-kolumnen i Money magazine. Den främsta anledningen till att det inte finns något behov av ett datum i denna URI är att det inte finns någon anledning att lagra den URI som kommer att överleva loggen. Begreppet Money Daily kommer att försvinna när Money försvinner. Om du vill länka till innehåll ska du länka till det separat i arkivet:

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

(Ser bra ut. Antar att "pengar" kommer att betyda samma sak under hela livet av pathfinder.com. Det finns en dubblett av "98" och en onödig ".html", men ser annars ut som en stark URI.

Vad man ska lämna åt sidan

Allt! Bortsett från datumet för skapandet, är att lägga in all information i URI:n fråga om problem på ett eller annat sätt.

Författarens namn. Författarskapet kan ändras när nya versioner blir tillgängliga. Människor lämnar organisationer och skickar saker vidare till andra.
ämne. Det är väldigt svårt. Det ser alltid bra ut i början, men förändras förvånansvärt snabbt. Jag ska prata mer om detta nedan.
Status. Kataloger som "gammalt", "utkast" och så vidare, för att inte tala om "senast" och "cool", visas i alla filsystem. Dokument ändrar status - annars vore det ingen idé att skapa utkast. Den senaste versionen av ett dokument behöver en beständig identifierare, oavsett dess status. Håll statusen borta från namnet.
Tillgång. På W3C har vi delat upp sajten i sektioner för personal, medlemmar och allmänheten. Detta låter bra, men naturligtvis börjar dokument som teamidéer från personalen, diskuteras med medlemmarna och blir sedan allmänt kända. Det skulle verkligen vara synd om varje gång ett dokument öppnas för vidare diskussion, så bryts alla gamla länkar till det! Nu går vi vidare till en enkel datumkod.
Filtillägg. Ett mycket vanligt fenomen. "cgi", även ".html" kommer att ändras i framtiden. Du kanske inte använder HTML för den här sidan på 20 år, men dagens länkar till den borde fortfarande fungera. Kanoniska länkar på W3C-webbplatsen använder inte tillägget (hur det är gjort).
Mjukvarumekanismer. I URI:n, leta efter "cgi", "exec" och andra termer som skriker "titta på vilken programvara vi använder." Vill någon ägna hela sitt liv åt att skriva Perl CGI-skript? Nej? Ta sedan bort tillägget .pl. Läs servermanualen om hur du gör detta.
Disknamn. Kom igen! Men jag har sett det här.

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

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

... rapportera om protokollet från W3C-ordförandemötet.

Ämnen och klassificering efter ämne

Jag kommer att gå in mer i detalj på denna fara, eftersom det är en av de saker som är svårast att undvika. Vanligtvis hamnar ämnen i URI:er när du kategoriserar dina dokument efter det arbete de gör. Men denna uppdelning kommer att förändras över tiden. Namnen på områdena kommer att ändras. På W3C ville vi ändra MarkUP till Markup och sedan till HTML för att återspegla det faktiska innehållet i avsnittet. Dessutom finns det ofta ett platt namnutrymme. Om 100 år, är du säker på att du inte vill återanvända någonting? Under vårt korta liv har vi redan velat återanvända "Historia" och "Style Sheets" till exempel.

Det är ett frestande sätt att organisera en webbplats – och ett verkligt frestande sätt att organisera vad som helst, inklusive hela webben. Detta är en bra lösning på medellång sikt men har allvarliga brister på lång sikt.

En del av anledningen ligger i meningsfilosofin. Varje term i ett språk är ett potentiellt mål för klustring, och varje person kan ha en annan uppfattning om vad det betyder. Eftersom relationer mellan enheter är mer som en webb än ett träd, kan även de som håller med webben välja en annan representation av trädet. Detta är mina (ofta upprepade) allmänna iakttagelser om farorna med hierarkisk klassificering som en allmän lösning.

Faktum är att när du använder ett ämnesnamn i en URI, förbinder du dig till någon form av klassificering. Kanske kommer du att föredra ett annat alternativ i framtiden. URI:n kommer då att vara mottaglig för överträdelse.

Anledningen till att man använder ett ämnesområde som en del av en URI är att ansvaret för undersektioner av URI-utrymmet vanligtvis delegeras, och då behöver du namnet på organisationsorganet - avdelning, grupp eller vad som helst - som ansvarar för det underutrymmet. Detta är en URI som binder till en organisationsstruktur. Det är vanligtvis bara säkert om den ytterligare (vänster) URI:n är skyddad av ett datum: 1998/pics kan för din server betyda "vad vi menade 1998 med bilder" snarare än "vad 1998 gjorde vi med vad vi nu kallar bilder."

Glöm inte domännamnet

Kom ihåg att detta inte bara gäller sökvägen i URI:n, utan även servernamnet. Om du har separata servrar för olika saker, kom ihåg att denna uppdelning kommer att vara omöjlig att ändra utan att förstöra många, många länkar. Några klassiska "titta på mjukvaran vi använder idag"-misstag är domännamnen "cgi.pathfinder.com", "secure", "lists.w3.org". De är utformade för att göra serveradministrationen enklare. Oavsett om en domän representerar en division i ditt företag, en dokumentstatus, en åtkomstnivå eller en säkerhetsnivå, var mycket, mycket försiktig innan du använder mer än ett domännamn för flera dokumenttyper. Kom ihåg att du kan dölja flera webbservrar inuti en enda synlig webbserver med hjälp av omdirigering och proxy.

Åh, och tänk också på ditt domännamn. Du vill inte bli kallad soap.com efter att du har bytt produktlinje och slutat tillverka tvål (Ursäkta den som äger soap.com för tillfället).

Slutsats

Att bevara en URI i 2, 20, 200 eller till och med 2000 år är uppenbarligen inte så lätt som det verkar. Men över hela Internet fattar webbansvariga beslut som gör denna uppgift riktigt svår för sig själva i framtiden. Ofta beror det på att de använder verktyg vars uppgift är att presentera den bästa sajten bara för tillfället – 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 många, många saker kan förändras, och dina URI:er kan och bör förbli desamma. Detta är bara möjligt när du tänker på hur du skapar dem.

Se även:

Jakob Nielsens tirad i samma ämne

kosttillskott

Hur man tar bort filtillägg...

...från en URI i den aktuella filbaserade webbservern?

Om du till exempel använder Apache kan du konfigurera den för att förhandla innehåll. Spara filtillägget (t.ex. .png) till en fil (t.ex. mydog.png), men du kan länka till en webbresurs utan den. Apache kontrollerar sedan katalogen efter alla filer med det namnet och eventuella tillägg, och kan välja den bästa från uppsättningen (till exempel GIF och PNG). Och det finns ingen anledning att placera olika typer av filer i olika kataloger, i själva verket fungerar inte innehållsmatchning om du gör det.

Ställ in din server för att förhandla innehåll
Länka alltid till URI utan förlängning

Länkar med tillägg kommer fortfarande att fungera, men kommer att hindra din server från att välja det bästa tillgängliga formatet för närvarande och i framtiden.

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

Naturligtvis, om du skriver din egen webbserver, är det en bra idé att använda en databas för att binda beständiga identifierare till deras nuvarande form, även om akta dig för obegränsad databastillväxt.

The Board of Shame - Berättelse 1: Kanal 7

Under 1999 spårade jag skolavslutningar på grund av snö på sidan http://www.whdh.com/stormforce/closings.shtml. Vänta inte tills informationen dyker upp längst ner på TV-skärmen! Jag länkade till den från min hemsida. Den första stora snöstormen 2000 anländer och jag kollar sidan. Där står det:,

- Från och med.
Inget är för närvarande stängt. Återkom gärna vid vädervarningar.

Det kan inte vara en så stark storm. Det är roligt att datumet saknas. Men om du går till sidans huvudsida kommer det att finnas en stor knapp "Stängda skolor", som leder till sidan http://www.whdh.com/stormforce/ med en lång rad stängda skolor.

Kanske ändrade de systemet för att få listan - men de behövde inte ändra URI.

Board of Shame - Berättelse 2: Microsoft Netmeeting

Med det växande beroendet av Internet kom en smart idé att länkar till tillverkarens webbplats kunde bäddas in i applikationer. Detta har använts och missbrukats mycket, men du kan inte ändra webbadressen. Häromdagen försökte jag en länk från Microsoft Netmeeting 2/something-klienten i menyn Hjälp/Microsoft på webben/gratis saker och fick ett 404-fel - inget svar från servern hittades. Kanske är det redan fixat...

Historisk anteckning: I slutet av 20-talet, när detta skrevs, var "cool" ett epitet av godkännande, särskilt bland unga människor, vilket tyder på mode, kvalitet eller lämplighet. I all hast valdes URI-vägen ofta för "coolness" snarare än användbarhet eller hållbarhet. Det här inlägget är ett försök att omdirigera energin bakom sökandet efter cool.

Källa: will.com

Coola URI:er ändras inte