Forfatter: Sir Tim Berners-Lee, opfinder af URI'er, URL'er, HTTP, HTML og World Wide Web, og nuværende leder af W3C. Artikel skrevet i 1998

Hvilken URI betragtes som "cool"?
En der ikke ændrer sig.
Hvordan ændres URI'er?
URI'er ændrer sig ikke: folk ændrer dem.

I teorien er der ingen grund til, at folk skal ændre URI'er (eller stoppe med støttedokumenter), men i praksis er der millioner af dem.

I teorien ejer den nominelle ejer af et domænenavneområde faktisk domænenavneområdet og derfor alle URI'erne i det. Bortset fra insolvens er der intet, der forhindrer ejeren af ​​et domænenavn i at beholde navnet. Og i teorien er URI-rummet under dit domænenavn helt under din kontrol, så du kan gøre det så stabilt, som du vil. Stort set den eneste gode grund til, at et dokument forsvinder fra internettet, er, at virksomheden, der ejede domænenavnet, er gået konkurs eller ikke længere har råd til at holde serveren kørende. Hvorfor er der så mange manglende led i verden? Noget af dette er simpelthen mangel på omtanke. Her er nogle grunde til, du måske hører:

Vi har lige omorganiseret siden for at gøre den bedre.

Tror du virkelig, at de gamle URI'er ikke kan fungere længere? Hvis ja, så har du valgt dem meget dårligt. Overvej at beholde de nye til næste redesign.

Vi har så mange ting, at vi ikke kan holde styr på, hvad der er forældet, hvad der er fortroligt, og hvad der stadig er relevant, så vi tænkte, at det var bedst bare at slå det hele fra.

Jeg kan kun sympatisere. W3C gennemgik en periode, hvor vi var nødt til omhyggeligt at gennemsøge arkivmateriale for fortrolighed, før det blev offentliggjort. Beslutningen skal være gennemtænkt på forhånd - sørg for, at du med hvert dokument registrerer det acceptable læsertal, oprettelsesdatoen og ideelt set udløbsdatoen. Gem disse metadata.

Nå, vi opdagede, at vi er nødt til at flytte filer...

Dette er en af ​​de mest patetiske undskyldninger. Mange mennesker ved ikke, at webservere giver dig mulighed for at kontrollere forholdet mellem et objekts URI og dets faktiske placering i filsystemet. Tænk på URI-rummet som et abstrakt rum, perfekt organiseret. Lav derefter en kortlægning til den virkelighed, du rent faktisk bruger til at realisere den. Rapporter derefter dette til webserveren. Du kan endda skrive dit eget serverstykke for at få det rigtigt.

John vedligeholder ikke længere denne fil, det gør Jane nu.

Var Johns navn i URI'en? Nej, var filen bare i hans mappe? Nå okay.

Tidligere brugte vi et CGI-script til dette, men nu bruger vi et binært program.

Der er en skør idé om, at sider oprettet af scripts skal være placeret i "cgibin" eller "cgi" området. Dette afslører mekanikken i, hvordan du kører din webserver. Du ændrer mekanismen (selv mens du gemmer indhold), og ups - alle dine URI'er ændres.

Tag National Science Foundation (NSF) for eksempel:

NSF online dokumenter

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

Den første side for at begynde at se dokumenter vil tydeligvis ikke forblive den samme om et par år. cgi-bin, oldbrowse и pl - alt dette giver stykker information om, hvordan-vi-gør-det-nu. Hvis du bruger siden til at søge efter et dokument, er det første resultat, du får, lige så dårligt:

Rapport fra arbejdsgruppen for kryptologi og kodningsteori

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

for dokumentindekssiden, selvom selve html-dokumentet ser meget bedre ud:

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

Her vil pubber/1998-headeren give enhver fremtidig arkivtjeneste et godt fingerpeg om, at den gamle dokumentklassifikationsordning fra 1998 er i kraft. Selvom dokumentnumrene kan se anderledes ud i 2098, kan jeg forestille mig, at denne URI stadig ville være gyldig og ikke ville forstyrre NSF eller nogen anden organisation, der ville vedligeholde arkivet.

Jeg troede ikke, at URL'er behøvede at være vedvarende – der var URN'er.

Dette er nok en af ​​de værste bivirkninger af URN-debatten. Nogle mennesker tror, ​​at på grund af forskningen i et mere permanent navneområde, kan de være skødesløse med at dingle links, fordi "URN'er vil ordne alt det." Hvis du er en af ​​disse mennesker, så lad mig skuffe dig.

De fleste URN-skemaer, jeg har set, ligner en autoritetsidentifikator efterfulgt af enten en dato og en streng, du vælger, eller bare en streng, du vælger. Dette minder meget om en HTTP URI. Med andre ord, hvis du tror, ​​at din organisation vil være i stand til at skabe URN'er med lang levetid, så bevis det nu ved at bruge dem til dine HTTP URI'er. Der er intet i selve HTTP, der gør din URI ustabil. Kun din organisation. Opret en database, der knytter dokumentets URN til det aktuelle filnavn, og lad webserveren bruge det til rent faktisk at hente filerne.

Hvis du er nået til dette punkt, hvis du ikke har tid, penge og forbindelser til at udvikle noget software, så kan du angive følgende undskyldning:

Vi ville gerne, men vi har bare ikke de rigtige værktøjer.

Men du kan sympatisere med dette. Jeg er fuldstændig enig. Hvad du skal gøre er at tvinge webserveren til øjeblikkeligt at parse den vedvarende URI og returnere filen, uanset hvor den er gemt på dit nuværende skøre filsystem. Du vil gemme alle URI'er i en fil som en kontrol og til enhver tid holde databasen opdateret. Du ønsker at bevare forholdet mellem forskellige versioner og oversættelser af det samme dokument, og også opretholde en uafhængig kontrolsumrecord for at sikre, at filen ikke er beskadiget af en utilsigtet fejl. Og webservere kommer simpelthen ikke ud af boksen med disse funktioner. Når du vil oprette et nyt dokument, beder din redaktør dig om at angive en URI.

Du skal kunne ændre ejerskab, dokumentadgang, arkivniveausikkerhed osv. i URI-rummet uden at ændre URI'en.

Det er alt for dårligt. Men vi vil rette op på situationen. Hos W3C bruger vi funktionaliteten Jigedit (Jigsaw editing server), der sporer versioner, og vi eksperimenterer med dokumentgenereringsscripts. Hvis du udvikler værktøjer, servere og klienter, skal du være opmærksom på dette problem!

Denne undskyldning gælder også for mange W3C-sider, inklusive denne: så gør som jeg siger, ikke som jeg gør.

Hvorfor skulle jeg bekymre mig?

Når du ændrer URI'en på din server, kan du aldrig helt se, hvem der skal have links til den gamle URI. Disse kan være links fra almindelige websider. Bogmærk din side. URI'en kan være blevet nedkradset i margenen af ​​et brev til en ven.

Når nogen følger et link, og det er brudt, mister de normalt tilliden til serverejeren. Han er også frustreret, både følelsesmæssigt og fysisk, over ikke at kunne nå sit mål.

Mange mennesker klager hele tiden over ødelagte links, og jeg håber, at skaden er åbenbar. Jeg håber, at skaden på omdømmet for vedligeholderen af ​​serveren, hvor dokumentet forsvandt, også er indlysende.

Så hvad skal jeg gøre? URI design

Det er webmasterens ansvar at tildele URI'er, der kan bruges om 2 år, om 20 år, om 200 år. Dette kræver omtanke, organisation og beslutsomhed.

URI'er ændres, hvis nogen oplysninger i dem ændres. Hvordan du designer dem er meget vigtigt. (Hvad, URI-design? Skal jeg designe URI? Ja, det bør du tænke over). Design betyder grundlæggende at udelade enhver information i URI'en.

Datoen dokumentet blev oprettet - datoen URI'en blev udstedt - er noget, der aldrig vil ændre sig. Det er meget nyttigt til at adskille forespørgsler, der bruger det nye system, fra dem, der bruger det gamle system. Dette er et godt sted at starte med en URI. Hvis et dokument er dateret, selvom dokumentet bliver relevant i fremtiden, så er det en god start.

Den eneste undtagelse er en side, der med vilje er den "nyeste" version, for eksempel for hele organisationen eller en stor del af den.

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

Dette er den seneste Money Daily-klumme i Money magazine. Hovedårsagen til, at der ikke er behov for en dato i denne URI, er, at der ikke er nogen grund til at gemme den URI, der vil overleve loggen. Begrebet Money Daily vil forsvinde, når Money forsvinder. Hvis du ønsker at linke til indhold, skal du linke til det separat i arkiverne:

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

(Ser godt ud. Antager, at "penge" vil betyde det samme gennem pathfinder.coms levetid. Der er en dublet "98" og en unødvendig ".html", men ligner ellers en stærk URI.

Hvad skal man lade være

Alle! Bortset fra oprettelsesdatoen, beder det om problemer på den ene eller den anden måde at sætte enhver information i URI'en.

• Forfatterens navn. Forfatterskab kan ændre sig, efterhånden som nye versioner bliver tilgængelige. Folk forlader organisationer og giver tingene videre til andre.
• emne. Det er meget svært. Det ser altid godt ud i starten, men ændrer sig overraskende hurtigt. Jeg vil fortælle mere om dette nedenfor.
• Status. Mapper som "gammelt", "udkast" og så videre, for ikke at nævne "senest" og "cool", vises i alle filsystemer. Dokumenter ændrer status - ellers ville det ikke nytte noget at lave kladder. Den seneste version af et dokument kræver en vedvarende identifikator, uanset dets status. Hold status ude af navnet.
• Adgang. Hos W3C har vi opdelt siden i sektioner for medarbejdere, medlemmer og offentligheden. Det lyder godt, men dokumenter starter selvfølgelig som teamideer fra personalet, diskuteres med medlemmer og bliver derefter offentligt kendt. Det ville virkelig være en skam, hvis hver gang et dokument åbnes for bredere diskussion, bliver alle de gamle links til det brudt! Nu går vi videre til en simpel datokode.
• Filtypenavn. En meget almindelig begivenhed. "cgi", selv ".html" vil ændre sig i fremtiden. Du bruger muligvis ikke HTML til denne side i 20 år, men dagens links til den burde stadig fungere. Kanoniske links på W3C-webstedet bruger ikke udvidelsen (hvordan det gøres).
• Software mekanismer. I URI'en skal du se efter "cgi", "exec" og andre udtryk, der skriger "se på hvilken software vi bruger." Er der nogen, der ønsker at bruge hele deres liv på at skrive Perl CGI-scripts? Ingen? Fjern derefter .pl-udvidelsen. Læs servermanualen om, hvordan du gør dette.
• Disknavn. Kom nu! Men jeg har set det her.

Så det bedste eksempel fra vores side er simpelthen

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

... rapportere om referatet fra W3C-formændsmødet.

Emner og klassificering efter emne

Jeg vil komme nærmere ind på denne fare, da det er en af ​​de ting, der er sværest at undgå. Typisk ender emner i URI'er, når du kategoriserer dine dokumenter efter det arbejde, de udfører. Men denne opdeling vil ændre sig over tid. Navnene på områderne ændres. Hos W3C ønskede vi at ændre MarkUP til Markup og derefter til HTML for at afspejle det faktiske indhold i afsnittet. Derudover er der ofte et fladt navneområde. Om 100 år, er du sikker på, at du ikke vil genbruge noget? I vores korte liv har vi allerede ønsket at genbruge "Historie" og "Style Sheets" for eksempel.

Det er en fristende måde at organisere et websted på – og en virkelig fristende måde at organisere alt på, inklusive hele nettet. Dette er en fantastisk løsning på mellemlang sigt, men har alvorlige mangler på lang sigt.

En del af årsagen ligger i meningsfilosofien. Hvert udtryk i et sprog er et potentielt mål for klyngedannelse, og hver person kan have en anden idé om, hvad det betyder. Da relationer mellem entiteter mere ligner et net end et træ, kan selv dem, der er enige med nettet, vælge en anden repræsentation af træet. Dette er mine (ofte gentagne) generelle observationer om farerne ved hierarkisk klassificering som en generel løsning.

Faktisk, når du bruger et emnenavn i en URI, forpligter du dig selv til en form for klassifikation. Måske vil du i fremtiden foretrække en anden mulighed. URI'en vil derefter være modtagelig for overtrædelse.

Grunden til at bruge et fagområde som en del af en URI er, at ansvaret for underafsnit af URI-rummet normalt er uddelegeret, og så skal du bruge navnet på den organisatoriske instans - afdeling, gruppe eller hvad som helst - der er ansvarlig for det underrum. Dette er en URI, der er bindende til en organisationsstruktur. Det er normalt kun sikkert, hvis den yderligere (venstre) URI er beskyttet af en dato: 1998/billeder kan for din server betyde "hvad vi mente i 1998 med billeder" i stedet for "hvad vi i 1998 gjorde med det, vi nu kalder billeder."

Glem ikke domænenavnet

Husk, at dette ikke kun gælder stien i URI'en, men også servernavnet. Hvis du har separate servere til forskellige ting, så husk at denne opdeling vil være umulig at ændre uden at ødelægge mange, mange links. Nogle klassiske "se på den software, vi bruger i dag"-fejl er domænenavne "cgi.pathfinder.com", "secure", "lists.w3.org". De er designet til at gøre serveradministration lettere. Uanset om et domæne repræsenterer en division i din virksomhed, en dokumentstatus, et adgangsniveau eller et sikkerhedsniveau, skal du være meget, meget forsigtig, før du bruger mere end ét domænenavn til flere dokumenttyper. Husk, at du kan skjule flere webservere inde i en enkelt synlig webserver ved hjælp af omdirigering og proxy.

Åh, og tænk også på dit domænenavn. Du ønsker ikke at blive omtalt som soap.com, efter du har ændret produktlinje og stoppet med at lave sæbe (beklager den, der ejer soap.com i øjeblikket).

Konklusion

At bevare en URI i 2, 20, 200 eller endda 2000 år er naturligvis ikke så let, som det ser ud til. Men over hele internettet træffer webmastere beslutninger, der gør denne opgave virkelig vanskelig for dem selv i fremtiden. Ofte skyldes det, at de bruger værktøjer, hvis opgave er kun at præsentere den bedste side i øjeblikket – og ingen har vurderet, hvad der skal ske med links, når alt ændrer sig. Men pointen her er, at mange, mange ting kan ændre sig, og dine URI'er kan og bør forblive de samme. Dette er kun muligt, når du tænker over, hvordan du skaber dem.

Se også:

• Jakob Nielsens tirade om samme emne

Kosttilskud

Sådan fjerner du filtypenavne...

...fra en URI i den aktuelle filbaserede webserver?

Hvis du for eksempel bruger Apache, kan du konfigurere den til at forhandle indhold. Gem filtypenavnet (f.eks. .png) til en fil (f.eks. mydog.png), men du kan linke til en webressource uden den. Apache kontrollerer derefter mappen for alle filer med det navn og enhver udvidelse og kan vælge den bedste fra sættet (for eksempel GIF og PNG). Og der er ingen grund til at placere forskellige typer filer i forskellige mapper, faktisk vil indholdsmatchning ikke fungere, hvis du gør det.

• Konfigurer din server til at forhandle indhold
• Link altid til URI'er uden forlængelse

Links med udvidelser vil stadig fungere, men vil forhindre din server i at vælge det bedste tilgængelige format i øjeblikket og i fremtiden.

(Faktisk, mydog, mydog.png и mydog.gif — gyldige webressourcer, mydog er en universel indholdstype ressource, og mydog.png и mydog.gif — ressourcer af en bestemt indholdstype).

Hvis du skriver din egen webserver, er det selvfølgelig en god idé at bruge en database til at binde vedvarende identifikatorer til deres nuværende form, men pas på med ubegrænset databasevækst.

The Board of Shame - Historie 1: Kanal 7

I løbet af 1999 sporede jeg skolelukninger på grund af sne på side http://www.whdh.com/stormforce/closings.shtml. Vent ikke på, at oplysningerne vises nederst på tv-skærmen! Jeg linkede til det fra min hjemmeside. Den første store snestorm i 2000 ankommer, og jeg tjekker siden. Der står skrevet:,

- Fra.
Intet er i øjeblikket lukket. Venligst vend tilbage i tilfælde af vejrvarsler.

Det kan ikke være så kraftig en storm. Det er sjovt, at datoen mangler. Men hvis du går til hjemmesidens hovedside, vil der være en stor knap "Lukkede skoler", som fører til siden http://www.whdh.com/stormforce/ med en lang række lukkede skoler.

Måske ændrede de systemet til at få listen - men de behøvede ikke at ændre URI'en.

Board of Shame - Historie 2: Microsoft Netmeeting

Med den voksende afhængighed af internettet kom der en smart idé om, at links til producentens hjemmeside kunne indlejres i applikationer. Dette er blevet brugt og misbrugt meget, men du kan ikke ændre URL'en. Forleden prøvede jeg et link fra Microsoft Netmeeting 2/noget-klienten i menuen Hjælp/Microsoft på nettet/gratis ting og modtog en 404-fejl - intet svar fra serveren blev fundet. Måske er det allerede rettet...

© 1998 Tim BL

Historisk note: I slutningen af ​​det 20. århundrede, da dette blev skrevet, var "cool" et epitet af godkendelse, især blandt unge, hvilket indikerer mode, kvalitet eller passende. I en fart blev URI-stien ofte valgt for "coolness" frem for anvendelighed eller holdbarhed. Dette indlæg er et forsøg på at omdirigere energien bag søgen efter cool.

Kilde: www.habr.com