Forfatter: Sir Tim Berners-Lee, oppfinner av URIer, URLer, HTTP, HTML og World Wide Web, og nåværende leder av W3C. Artikkel skrevet i 1998

Hvilken URI anses som "kul"?
En som ikke endrer seg.
Hvordan endres URIer?
URIer endres ikke: folk endrer dem.

I teorien er det ingen grunn for folk til å endre URI (eller slutte med støttedokumenter), men i praksis er det millioner av dem.

I teorien eier den nominelle eieren av et domenenavneområde faktisk domenenavneområdet og derfor alle URIene i det. Bortsett fra insolvens er det ingenting som hindrer eieren av et domenenavn fra å beholde navnet. Og i teorien er URI-plassen under domenenavnet ditt helt og holdent under din kontroll, så du kan gjøre det så stabilt du vil. Stort sett den eneste gode grunnen til at et dokument forsvinner fra internett er at selskapet som eide domenenavnet har gått ut av drift eller ikke lenger har råd til å holde serveren i gang. Så hvorfor er det så mange manglende lenker i verden? Noe av dette er rett og slett mangel på omtanke. Her er noen grunner du kan høre:

Vi har nettopp omorganisert nettstedet for å gjøre det bedre.

Tror du virkelig at de gamle URI-ene ikke kan fungere lenger? I så fall valgte du dem veldig dårlig. Vurder å beholde de nye for neste redesign.

Vi har så mye ting at vi ikke kan holde styr på hva som er utdatert, hva som er konfidensielt og hva som fortsatt er relevant, så vi tenkte det var best å bare slå av alt.

Jeg kan bare sympatisere. W3C gjennomgikk en periode hvor vi måtte sile nøye gjennom arkivmateriale for konfidensialitet før vi offentliggjorde dem. Avgjørelsen bør tenkes gjennom på forhånd - sørg for at du med hvert dokument registrerer akseptabelt lesertall, opprettelsesdato og, ideelt sett, utløpsdato. Lagre disse metadataene.

Vel, vi oppdaget at vi må flytte filer...

Dette er en av de mest patetiske unnskyldningene. Mange vet ikke at webservere lar deg kontrollere forholdet mellom et objekts URI og dets faktiske plassering i filsystemet. Tenk på URI-rommet som et abstrakt rom, perfekt organisert. Lag deretter en kartlegging til hvilken virkelighet du faktisk bruker for å realisere den. Rapporter deretter dette til webserveren. Du kan til og med skrive din egen serverkodebit for å få den riktig.

John vedlikeholder ikke lenger denne filen, det gjør Jane nå.

Var Johns navn i URI? Nei, var filen bare i katalogen hans? Vel ok.

Tidligere brukte vi et CGI-skript til dette, men nå bruker vi et binært program.

Det er en sprø idé at sider som er opprettet av skript skal være plassert i "cgibin"- eller "cgi"-området. Dette avslører mekanikken i hvordan du kjører webserveren din. Du endrer mekanismen (selv mens du lagrer innhold), og ups - alle URIene dine endres.

Ta National Science Foundation (NSF) for eksempel:

NSF online dokumenter

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

Den første siden for å begynne å se dokumenter vil tydeligvis ikke forbli den samme om noen år. cgi-bin, oldbrowse и pl - alt dette gir ut biter av informasjon om hvordan-vi-gjør-det-nå. Hvis du bruker siden til å søke etter et dokument, er det første resultatet du får like dårlig:

Rapport fra arbeidsgruppen for kryptologi og kodingsteori

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

for dokumentindekssiden, selv om html-dokumentet i seg selv ser mye bedre ut:

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

Her vil overskriften puber/1998 gi enhver fremtidig arkivtjeneste en god pekepinn på at den gamle dokumentklassifiseringsordningen fra 1998 er i kraft. Selv om dokumenttallene kan se annerledes ut i 2098, kan jeg tenke meg at denne URIen fortsatt vil være gyldig og ikke forstyrre NSF eller noen annen organisasjon som vil vedlikeholde arkivet.

Jeg trodde ikke URL-er måtte være vedvarende – det var URN-er.

Dette er trolig en av de verste bivirkningene av URN-debatten. Noen mennesker tror at på grunn av forskningen på et mer permanent navneområde, kan de være uforsiktige med å dingle lenker fordi "URN-er vil fikse alt dette." Hvis du er en av disse personene, så la meg skuffe deg.

De fleste URN-skjemaer jeg har sett ser ut som en autoritetsidentifikator etterfulgt av enten en dato og en streng du velger, eller bare en streng du velger. Dette ligner veldig på en HTTP URI. Med andre ord, hvis du tror organisasjonen din vil være i stand til å lage URN-er med lang levetid, så bevis det nå ved å bruke dem for HTTP-URI-ene dine. Det er ingenting i HTTP i seg selv som gjør URIen din ustabil. Bare din organisasjon. Lag en database som tilordner dokumentets URN til gjeldende filnavn, og la webserveren bruke den til å faktisk hente filene.

Hvis du har nådd dette punktet, hvis du ikke har tid, penger og forbindelser til å utvikle noe programvare, kan du oppgi følgende unnskyldning:

Vi ønsket det, men vi har rett og slett ikke de riktige verktøyene.

Men du kan sympatisere med dette. Jeg er helt enig. Det du trenger å gjøre er å tvinge webserveren til umiddelbart å analysere den vedvarende URI-en og returnere filen uansett hvor den er lagret på ditt nåværende gale filsystem. Du vil lagre alle URIer i en fil som en sjekk og holde databasen oppdatert til enhver tid. Du ønsker å bevare forholdet mellom forskjellige versjoner og oversettelser av det samme dokumentet, og også opprettholde en uavhengig kontrollsumpost for å sikre at filen ikke blir ødelagt av en utilsiktet feil. Og webservere kommer rett og slett ikke ut av esken med disse funksjonene. Når du vil opprette et nytt dokument, ber redaktøren din om å spesifisere en URI.

Du må kunne endre eierskap, dokumenttilgang, arkivnivåsikkerhet osv. i URI-området uten å endre URI.

Det er alt for dårlig. Men vi vil rette opp situasjonen. På W3C bruker vi funksjonaliteten Jigedit (Jigsaw editing server) som sporer versjoner, og vi eksperimenterer med dokumentgenereringsskript. Hvis du utvikler verktøy, servere og klienter, vær oppmerksom på dette problemet!

Denne unnskyldningen gjelder også for mange W3C-sider, inkludert denne: så gjør som jeg sier, ikke som jeg gjør.

Hvorfor skal jeg bry meg?

Når du endrer URI på serveren din, kan du aldri helt si hvem som skal ha linker til den gamle URI. Dette kan være lenker fra vanlige nettsider. Bokmerk siden din. URI-en kan ha blitt skriblet i kantene på et brev til en venn.

Når noen følger en kobling og den blir ødelagt, mister de vanligvis tilliten til servereieren. Han er også frustrert, både følelsesmessig og fysisk, over ikke å kunne nå målet sitt.

Mange klager på ødelagte lenker hele tiden, og jeg håper skaden er åpenbar. Jeg håper at omdømmeskaden til vedlikeholderen av serveren der dokumentet forsvant også er åpenbar.

Så hva bør jeg gjøre? URI design

Det er nettredaktørens ansvar å tildele URIer som kan brukes om 2 år, om 20 år, om 200 år. Dette krever omtanke, organisering og besluttsomhet.

URI-er endres hvis informasjonen i dem endres. Hvordan du designer dem er veldig viktig. (Hva, URI-design? Trenger jeg å designe URI? Ja, du bør tenke på det). Design betyr i utgangspunktet å utelate all informasjon i URI.

Datoen dokumentet ble opprettet - datoen URI ble utstedt - er noe som aldri vil endres. Det er veldig nyttig for å skille spørringer som bruker det nye systemet fra de som bruker det gamle systemet. Dette er et bra sted å starte med en URI. Dersom et dokument er datert, selv om dokumentet vil være aktuelt i fremtiden, så er dette en god start.

Det eneste unntaket er en side som med vilje er den «nyeste» versjonen, for eksempel for hele organisasjonen eller store deler av den.

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

Dette er den siste Money Daily-spalten i Money magazine. Hovedårsaken til at det ikke er behov for en dato i denne URIen er at det ikke er noen grunn til å lagre URIen som vil overleve loggen. Konseptet med Money Daily vil forsvinne når Money forsvinner. Hvis du ønsker å lenke til innhold, bør du lenke til det separat i arkivene:

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

(Ser bra ut. Antar at "penger" vil bety det samme gjennom hele livet til pathfinder.com. Det er en duplikat "98" og en unødvendig ".html", men ser ellers ut som en sterk URI.

Hva du skal legge til side

Alle! Bortsett fra opprettelsesdatoen, er det å legge inn informasjon i URI-en å be om problemer på en eller annen måte.

• Forfatterens navn. Forfatterskap kan endres etter hvert som nye versjoner blir tilgjengelige. Folk forlater organisasjoner og gir ting videre til andre.
• Emne. Det er veldig vanskelig. Det ser alltid bra ut i begynnelsen, men endrer seg overraskende raskt. Jeg skal snakke mer om dette nedenfor.
• Status. Kataloger som "gammelt", "utkast" og så videre, for ikke å snakke om "siste" og "kult", vises i alle filsystemer. Dokumenter endrer status – ellers er det ingen vits i å lage utkast. Den siste versjonen av et dokument trenger en vedvarende identifikator, uavhengig av status. Hold statusen utenfor navnet.
• Adgang. På W3C har vi delt siden inn i seksjoner for ansatte, medlemmer og publikum. Dette høres bra ut, men selvfølgelig starter dokumenter som teamideer fra ansatte, diskuteres med medlemmene og blir så offentlig kjent. Det ville virkelig være synd om hver gang et dokument åpnes for en bredere diskusjon, blir alle de gamle lenkene til det ødelagt! Nå går vi videre til en enkel datokode.
• Filutvidelse. Et veldig vanlig fenomen. "cgi", til og med ".html" vil endre seg i fremtiden. Du bruker kanskje ikke HTML for denne siden på 20 år, men dagens lenker til den skal fortsatt fungere. Kanoniske lenker på W3C-nettstedet bruker ikke utvidelsen (hvordan det gjøres).
• Programvaremekanismer. I URI, se etter "cgi", "exec" og andre termer som skriker "se på hvilken programvare vi bruker." Er det noen som ønsker å bruke hele livet på å skrive Perl CGI-skript? Nei? Fjern deretter .pl-utvidelsen. Les servermanualen om hvordan du gjør dette.
• Disknavn. Kom igjen! Men jeg har sett dette.

Så det beste eksemplet fra nettstedet vårt er ganske enkelt

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

... rapportere om referatet fra W3C-ledermøtet.

Emner og klassifisering etter emne

Jeg vil gå nærmere inn på denne faren, siden det er en av de tingene som er vanskeligst å unngå. Vanligvis havner emner i URIer når du kategoriserer dokumentene dine etter arbeidet de gjør. Men denne sammenbruddet vil endre seg over tid. Navnene på områdene vil endres. På W3C ønsket vi å endre MarkUP til Markup og deretter til HTML for å gjenspeile det faktiske innholdet i delen. I tillegg er det ofte et flatt navneområde. Om 100 år, er du sikker på at du ikke vil gjenbruke noe? I vårt korte liv har vi allerede ønsket å gjenbruke "Historie" og "Style Sheets" for eksempel.

Det er en fristende måte å organisere et nettsted på – og en virkelig fristende måte å organisere hva som helst, inkludert hele nettet. Dette er en flott løsning på mellomlang sikt, men har alvorlige mangler på lang sikt.

Noe av grunnen ligger i meningsfilosofien. Hvert begrep i et språk er et potensielt mål for gruppering, og hver person kan ha en annen idé om hva det betyr. Siden relasjoner mellom enheter er mer som et nett enn et tre, kan selv de som er enige med nettet velge en annen representasjon av treet. Dette er mine (ofte gjentatte) generelle observasjoner om farene ved hierarkisk klassifisering som en generell løsning.

Faktisk, når du bruker et emnenavn i en URI, forplikter du deg selv til en slags klassifisering. Kanskje du vil foretrekke et annet alternativ i fremtiden. URI-en vil da være mottakelig for brudd.

Grunnen til å bruke et fagområde som en del av en URI er at ansvaret for underseksjoner av URI-rommet vanligvis er delegert, og da trenger du navnet på organisasjonsorganet - avdeling, gruppe eller hva som helst - som er ansvarlig for det underrommet. Dette er en URI som er bindende til en organisasjonsstruktur. Det er vanligvis bare trygt hvis den videre (venstre) URIen er beskyttet av en dato: 1998/bilder kan for serveren din bety "hva vi mente i 1998 med bilder" i stedet for "hva vi gjorde i 1998 med det vi nå kaller bilder."

Ikke glem domenenavnet

Husk at dette ikke bare gjelder banen i URIen, men også servernavnet. Hvis du har separate servere for forskjellige ting, husk at denne inndelingen vil være umulig å endre uten å ødelegge mange, mange linker. Noen klassiske "se på programvaren vi bruker i dag"-feil er domenenavn "cgi.pathfinder.com", "secure", "lists.w3.org". De er designet for å gjøre serveradministrasjon enklere. Uansett om et domene representerer en avdeling i bedriften din, en dokumentstatus, et tilgangsnivå eller et sikkerhetsnivå, vær veldig, veldig forsiktig før du bruker mer enn ett domenenavn for flere dokumenttyper. Husk at du kan skjule flere webservere inne i én synlig webserver ved å bruke omdirigering og proxying.

Åh, og tenk også på domenenavnet ditt. Du ønsker ikke å bli referert til som soap.com etter at du har endret produktlinje og sluttet å lage såpe (Beklager til den som eier soap.com for øyeblikket).

Konklusjon

Å bevare en URI i 2, 20, 200 eller til og med 2000 år er åpenbart ikke så lett som det ser ut til. Men over hele Internett tar nettredaktører beslutninger som gjør denne oppgaven veldig vanskelig for seg selv i fremtiden. Ofte er dette fordi de bruker verktøy som har som jobb å presentere den beste siden kun for øyeblikket – og ingen har vurdert hva som vil skje med lenkene når alt endres. Men poenget her er at mange, mange ting kan endre seg, og URIene dine kan og bør forbli de samme. Dette er bare mulig når du tenker på hvordan du lager dem.

Se også:

• Jakob Nielsens tirade om samme tema

kosttilskudd

Slik fjerner du filtypene...

...fra en URI i den gjeldende filbaserte webserveren?

Hvis du for eksempel bruker Apache, kan du konfigurere den til å forhandle innhold. Lagre filtypen (f.eks. .png) til en fil (f.eks. mydog.png), men du kan koble til en nettressurs uten den. Apache sjekker deretter katalogen for alle filer med det navnet og eventuelle utvidelser, og kan velge den beste fra settet (for eksempel GIF og PNG). Og det er ikke nødvendig å legge forskjellige typer filer i forskjellige kataloger, faktisk vil ikke innholdsmatching fungere hvis du gjør det.

• Sett opp serveren din for å forhandle innhold
• Koble alltid til URIer uten utvidelse

Koblinger med utvidelser vil fortsatt fungere, men vil hindre serveren din fra å velge det beste formatet som er tilgjengelig nå og i fremtiden.

(Faktisk, mydog, mydog.png и mydog.gif – gyldige nettressurser, mydog er en universell innholdsressurs, og mydog.png и mydog.gif – ressurser av en bestemt innholdstype).

Selvfølgelig, hvis du skriver din egen webserver, er det en god idé å bruke en database for å binde vedvarende identifikatorer til deres nåværende form, men pass deg for ubegrenset databasevekst.

The Board of Shame - Historie 1: Kanal 7

I løpet av 1999 sporet jeg skolestengninger på grunn av snø på side http://www.whdh.com/stormforce/closings.shtml. Ikke vent til informasjonen vises nederst på TV-skjermen! Jeg lenket til den fra hjemmesiden min. Den første store snøstormen på 2000 kommer og jeg sjekker siden. Der står det:,

- Pr.
Ingenting er stengt for øyeblikket. Vennligst returner i tilfelle værvarsler.

Det kan ikke være en så sterk storm. Det er morsomt at datoen mangler. Men hvis du går til hovedsiden til nettstedet, vil det være en stor knapp "Stengte skoler", som fører til siden http://www.whdh.com/stormforce/ med en lang liste over stengte skoler.

Kanskje de endret systemet for å få listen - men de trengte ikke å endre URI.

Board of Shame - Historie 2: Microsoft Netmeeting

Med den økende avhengigheten av Internett kom en smart idé om at lenker til produsentens nettsted kunne bygges inn i applikasjoner. Dette har blitt brukt og misbrukt mye, men du kan ikke endre URL. Forleden dag prøvde jeg en kobling fra Microsoft Netmeeting 2/noe-klienten i Hjelp/Microsoft på nettet/gratis ting-menyen og fikk en 404-feil - ingen svar fra serveren ble funnet. Kanskje det allerede er fikset...

© 1998 Tim BL

Historisk merknad: På slutten av 20-tallet, da dette ble skrevet, var "kult" et epitet på godkjenning, spesielt blant unge mennesker, som indikerte mote, kvalitet eller passende. I all hast ble URI-banen ofte valgt for "kulhet" fremfor nytte eller holdbarhet. Dette innlegget er et forsøk på å omdirigere energien bak søket etter kult.

Kilde: www.habr.com