Autor: Sir Tim Berners-Lee, inventor d'URI, URL, HTTP, HTML i World Wide Web, i actual cap del W3C. Article escrit l'any 1998

Quina URI es considera "cool"?
Un que no canvia.
Com es canvien els URI?
Els URI no canvien: la gent els canvia.

En teoria, no hi ha cap motiu perquè la gent canviï els URI (o deixi de donar suport), però a la pràctica n'hi ha milions.

En teoria, el propietari nominal d'un espai de noms de domini en realitat és propietari de l'espai de noms de domini i, per tant, de tots els URI que hi ha dins. A part de la insolvència, res impedeix que el propietari d'un nom de domini mantingui el nom. I, en teoria, l'espai URI sota el vostre nom de domini està totalment sota el vostre control, de manera que podeu fer-lo tan estable com vulgueu. Pràcticament l'única raó bona perquè un document desaparegui d'Internet és que l'empresa propietaria del nom de domini ha quedat sense negoci o ja no es pot permetre el luxe de mantenir el servidor en funcionament. Aleshores, per què hi ha tants enllaços que falten al món? Part d'això és simplement una falta de previsió. Aquí hi ha alguns motius pels quals potser escolteu:

Acabem de reorganitzar el lloc per millorar-lo.

Creus realment que els antics URI ja no poden funcionar? Si és així, els has triat molt malament. Penseu en mantenir els nous per al proper redisseny.

Tenim tantes coses que no podem fer un seguiment del que està desactualitzat, del que és confidencial i del que encara és rellevant, així que vam pensar que era millor desactivar-ho tot.

Només puc simpatitzar. El W3C va passar per un període en què vam haver de tamisar amb cura els materials d'arxiu per a la confidencialitat abans de fer-los públics. La decisió s'ha de pensar amb antelació: assegureu-vos que amb cada document registreu el nombre de lectors acceptables, la data de creació i, idealment, la data de caducitat. Desa aquestes metadades.

Bé, hem descobert que hem de moure fitxers...

Aquesta és una de les excuses més patètiques. Molta gent no sap que els servidors web us permeten controlar la relació entre l'URI d'un objecte i la seva ubicació real al sistema de fitxers. Penseu en l'espai URI com un espai abstracte, perfectament organitzat. A continuació, feu un mapa a qualsevol realitat que utilitzeu per adonar-vos-en. A continuació, informeu-ho al servidor web. Fins i tot podeu escriure el vostre propi fragment de servidor per fer-ho bé.

John ja no manté aquest fitxer, ara fa la Jane.

El nom de John estava a l'URI? No, el fitxer estava només al seu directori? Bé, d'acord.

Abans hem utilitzat un script CGI per a això, però ara fem servir un programa binari.

Hi ha una idea boja que les pàgines creades per scripts s'han d'ubicar a l'àrea "cgibin" o "cgi". Això exposa la mecànica de com executeu el vostre servidor web. Canvieu el mecanisme (fins i tot mentre deseu contingut) i us, tots els vostres URI canvien.

Prengui per exemple la National Science Foundation (NSF):

Documents en línia de la NSF

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

És evident que la primera pàgina per començar a veure documents no es mantindrà igual d'aquí a uns anys. cgi-bin, oldbrowse и pl - tot això dóna informació sobre com ho fem ara. Si utilitzeu la pàgina per cercar un document, el primer resultat que obteniu és igualment dolent:

Informe del Grup de Treball de Criptologia i Teoria de la Codificació

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

per a la pàgina d'índex del document, tot i que el document html en si sembla molt millor:

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

Aquí la capçalera pubs/1998 donarà a qualsevol futur servei d'arxiu una bona pista que l'antic esquema de classificació de documents de 1998 està en vigor. Tot i que els números de document poden semblar diferents el 2098, m'imaginaria que aquest URI encara seria vàlid i no interferiria amb NSF o cap altra organització que mantindria l'arxiu.

No pensava que els URL haguessin de ser persistents: hi havia URN.

Aquest és probablement un dels pitjors efectes secundaris del debat URN. Algunes persones pensen que a causa de la investigació d'un espai de noms més permanent, podrien ser descuidats amb els enllaços penjants perquè "les URN solucionaran tot això". Si sou una d'aquestes persones, deixeu-me decebre.

La majoria dels esquemes d'URN que he vist semblen un identificador d'autoritat seguit d'una data i una cadena que seleccioneu, o només d'una cadena que seleccioneu. Això és molt semblant a un URI HTTP. En altres paraules, si creieu que la vostra organització serà capaç de crear URN de llarga vida, demostreu-ho ara utilitzant-los per als vostres URI HTTP. No hi ha res en el propi HTTP que faci que el vostre URI sigui inestable. Només la teva organització. Creeu una base de dades que mapeï l'URN del document amb el nom del fitxer actual i deixeu que el servidor web l'utilitzi per recuperar els fitxers.

Si heu arribat a aquest punt, si no teniu temps, diners i connexions per desenvolupar algun programari, podeu indicar la següent excusa:

Volíem, però no tenim les eines adequades.

Però pots simpatitzar amb això. Estic completament d'acord. El que heu de fer és forçar el servidor web a analitzar instantàniament l'URI persistent i tornar el fitxer allà on estigui emmagatzemat actualment al vostre sistema de fitxers boig actual. Voleu emmagatzemar tots els URI en un fitxer com a comprovació i mantenir la base de dades actualitzada en tot moment. Voleu preservar la relació entre les diferents versions i traduccions d'un mateix document, i també mantenir un registre de suma de comprovació independent per assegurar-vos que el fitxer no estigui malmès per un error accidental. I els servidors web simplement no surten de la caixa amb aquestes funcions. Quan voleu crear un document nou, el vostre editor us demana que especifiqueu un URI.

Heu de poder canviar la propietat, l'accés al document, la seguretat a nivell d'arxiu, etc. a l'espai URI sense canviar l'URI.

Està molt malament. Però corregim la situació. Al W3C, utilitzem la funcionalitat Jigedit (servidor d'edició Jigsaw) que fa un seguiment de les versions i experimentem amb scripts de generació de documents. Si desenvolupeu eines, servidors i clients, presteu atenció a aquest problema!

Aquesta excusa també s'aplica a moltes pàgines del W3C, inclosa aquesta: feu el que us dic, no com faig jo.

Per què m'hauria de preocupar?

Quan canvieu l'URI al vostre servidor, mai podreu dir completament qui tindrà enllaços a l'URI antic. Aquests poden ser enllaços de pàgines web habituals. Afegiu la vostra pàgina a les adreces d'interès. És possible que l'URI s'hagi dibuixat als marges d'una carta a un amic.

Quan algú segueix un enllaç i aquest es trenca, normalment perd la confiança en el propietari del servidor. També està frustrat, tant emocionalment com físicament, per no poder assolir el seu objectiu.

Molta gent es queixa d'enllaços trencats tot el temps, i espero que el dany sigui evident. Espero que també sigui evident el dany a la reputació del responsable del servidor on va desaparèixer el document.

Llavors què hauria de fer? Disseny d'URI

És responsabilitat de l'administrador web assignar URIs que es puguin utilitzar en 2 anys, en 20 anys, en 200 anys. Això requereix reflexió, organització i determinació.

Els URI canvien si canvia alguna informació. Com els dissenyeu és molt important. (Què, disseny d'URI? Necessito dissenyar l'URI? Sí, hauríeu de pensar-hi). Dissenyar bàsicament significa deixar de banda qualsevol informació a l'URI.

La data en què es va crear el document, la data en què es va emetre l'URI, és una cosa que no canviarà mai. És molt útil per separar les consultes que utilitzen el nou sistema de les que utilitzen el sistema antic. Aquest és un bon lloc per començar amb un URI. Si un document està datat, fins i tot si el document serà rellevant en el futur, aquest és un bon començament.

L'única excepció és una pàgina que és intencionadament la versió "darrera", per exemple per a tota l'organització o gran part d'aquesta.

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

Aquesta és la darrera columna Money Daily de la revista Money. La raó principal per la qual no cal una data en aquest URI és que no hi ha cap raó per emmagatzemar l'URI que sobreviurà al registre. El concepte de Money Daily desapareixerà quan Money desaparegui. Si voleu enllaçar-hi contingut, hauríeu d'enllaçar-hi per separat als arxius:

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

(Sembla bé. Se suposa que "diners" significarà el mateix durant tota la vida de pathfinder.com. Hi ha un "98" duplicat i un ".html" innecessari, però, en cas contrari, sembla un URI fort.

Què deixar de banda

Tot! A part de la data de creació, posar qualsevol informació a l'URI és demanar problemes d'una manera o altra.

• Nom de l'autor. L'autoria pot canviar a mesura que estiguin disponibles noves versions. La gent deixa les organitzacions i passa coses a altres.
• Assumpte. És molt difícil. Al principi sempre es veu bé, però canvia sorprenentment ràpidament. A continuació en parlaré més sobre això.
• Estat. A tots els sistemes de fitxers apareixen directoris com "vell", "esborrany", etc., per no parlar de "últim" i "cool". Els documents canvien d'estat; en cas contrari, no tindria sentit crear esborranys. La darrera versió d'un document necessita un identificador persistent, independentment del seu estat. Manteniu l'estat fora del nom.
• Accés. Al W3C, hem dividit el lloc en seccions per al personal, els membres i el públic. Això sona bé, però per descomptat, els documents comencen com idees d'equip dels empleats, es discuteixen amb els membres i després esdevenen de coneixement públic. Seria realment una llàstima que cada vegada que s'obre un document per a una discussió més àmplia, es trenquin tots els enllaços antics! Ara passem a un codi de data senzill.
• Extensió de fitxer. Un fenomen molt comú. "cgi", fins i tot ".html" canviarà en el futur. És possible que no feu servir HTML per a aquesta pàgina durant 20 anys, però els enllaços d'avui encara haurien de funcionar. Els enllaços canònics del lloc W3C no utilitzen l'extensió (com es fa).
• Mecanismes de programari. A l'URI, cerqueu "cgi", "exec" i altres termes que cridin "mira quin programari estem utilitzant". Algú vol passar tota la seva vida escrivint scripts CGI de Perl? No? A continuació, elimineu l'extensió .pl. Llegiu el manual del servidor sobre com fer-ho.
• Nom del disc. Vinga! Però això ho he vist.

Així que el millor exemple del nostre lloc és simplement

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

... informe sobre l'acta de la reunió de presidents del W3C.

Temes i classificació per temes

Aprofundiré més en aquest perill, ja que és una d'aquelles coses que és més difícil d'evitar. Normalment, els temes acaben als URI quan classifiqueu els vostres documents segons la feina que fan. Però aquesta ruptura canviarà amb el temps. Els noms de les zones canviaran. Al W3C volíem canviar MarkUP a Marcat i després a HTML per reflectir el contingut real de la secció. A més, sovint hi ha un espai de noms pla. D'aquí a 100 anys, estàs segur que no voldràs reutilitzar res? En la nostra curta vida ja hem volgut reutilitzar "Història" i "Fulls d'estil", per exemple.

És una manera temptadora d'organitzar un lloc web, i una manera realment temptadora d'organitzar qualsevol cosa, inclosa la web sencera. Aquesta és una gran solució a mitjà termini, però té greus deficiències a llarg termini.

Part de la raó rau en la filosofia del significat. Cada terme d'una llengua és un objectiu potencial per agrupar-se, i cada persona pot tenir una idea diferent del que significa. Com que les relacions entre entitats són més semblants a una xarxa que a un arbre, fins i tot aquells que estiguin d'acord amb la web poden triar una representació diferent de l'arbre. Aquestes són les meves observacions generals (sovint repetides) sobre els perills de la classificació jeràrquica com a solució general.

De fet, quan utilitzeu un nom de tema en una URI, us comprometeu a fer algun tipus de classificació. Potser en el futur preferiu una opció diferent. Aleshores, l'URI serà susceptible de violació.

El motiu d'utilitzar una àrea temàtica com a part d'una URI és que la responsabilitat de les subseccions de l'espai URI normalment es delega, i llavors necessiteu el nom de l'òrgan organitzatiu (departament, grup o el que sigui) que sigui responsable d'aquest subespai. Aquest és un URI vinculant a una estructura organitzativa. Normalment només és segur si l'URI més (esquerra) està protegit per una data: 1998/pics pot significar per al vostre servidor "el que volíem dir el 1998 amb les fotos" en lloc de "el que vam fer el 1998 amb el que ara anomenem fotos".

No oblidis el nom del domini

Recordeu que això s'aplica no només a la ruta de l'URI, sinó també al nom del servidor. Si teniu servidors separats per a coses diferents, recordeu que aquesta divisió serà impossible de canviar sense destruir molts, molts enllaços. Alguns errors clàssics de "mira el programari que fem servir avui en dia" són els noms de domini "cgi.pathfinder.com", "secure", "lists.w3.org". Estan dissenyats per facilitar l'administració del servidor. Independentment de si un domini representa una divisió a la vostra empresa, un estat de document, un nivell d'accés o un nivell de seguretat, aneu amb molta cura abans d'utilitzar més d'un nom de domini per a diversos tipus de documents. Recordeu que podeu amagar diversos servidors web dins d'un únic servidor web visible mitjançant la redirecció i el proxy.

Ah, i també pensa en el teu nom de domini. No voleu que us anomenin soap.com després de canviar les línies de productes i deixar de fer sabó (ho sento per a qui sigui propietari de soap.com en aquest moment).

Conclusió

Preservar una URI durant 2, 20, 200 o fins i tot 2000 anys, òbviament, no és tan fàcil com sembla. No obstant això, a tot Internet, els administradors web prenen decisions que els dificulten realment aquesta tasca en el futur. Sovint, això es deu al fet que utilitzen eines la feina de les quals és presentar el millor lloc només en aquest moment, i ningú no ha avaluat què passarà amb els enllaços quan tot canviï. Tanmateix, el punt aquí és que moltes, moltes coses poden canviar, i els vostres URI poden i haurien de romandre igual. Això només és possible quan penseu en com els creeu.

Veure també:

• La diatriba de Jakob Nielsen sobre el mateix tema

Addicions

Com eliminar les extensions de fitxer...

...des d'un URI al servidor web actual basat en fitxers?

Si utilitzeu Apache, per exemple, podeu configurar-lo per negociar contingut. Deseu l'extensió del fitxer (p. ex. .png) en un fitxer (p. ex. el meu gos.png), però podeu enllaçar a un recurs web sense ell. A continuació, Apache comprova al directori tots els fitxers amb aquest nom i qualsevol extensió, i pot triar el millor del conjunt (per exemple, GIF i PNG). I no cal posar diferents tipus de fitxers en diferents directoris, de fet, la concordança de contingut no funcionarà si ho feu.

• Configura el teu servidor per negociar contingut
• Enllaceu sempre als URI sense extensió

Els enllaços amb extensions continuaran funcionant, però evitaran que el vostre servidor escolliu el millor format disponible actualment i en el futur.

(De fet, mydog, mydog.png и mydog.gif — recursos web vàlids, mydog és un recurs de tipus de contingut universal i mydog.png и mydog.gif — recursos d'un tipus de contingut específic).

Per descomptat, si esteu escrivint el vostre propi servidor web, és una bona idea utilitzar una base de dades per vincular identificadors persistents a la seva forma actual, tot i que aneu amb compte amb el creixement il·limitat de la base de dades.

The Board of Shame - Història 1: Canal 7

Durant l'any 1999, vaig fer un seguiment dels tancaments d'escoles a causa de la neu a la pàgina http://www.whdh.com/stormforce/closings.shtml. No esperis que la informació aparegui a la part inferior de la pantalla del televisor! L'he enllaçat des de la meva pàgina d'inici. Arriba la primera gran tempesta de neu de l'any 2000 i comprovo la pàgina. Allà està escrit:,

- Com de.
Actualment no hi ha res tancat. Si us plau, torneu en cas d'avís meteorològic.

No pot ser una tempesta tan forta. És curiós que falti la data. Però si aneu a la pàgina principal del lloc, hi haurà un gran botó "Escoles tancades", que condueix a la pàgina http://www.whdh.com/stormforce/ amb una llarga llista d'escoles tancades.

Potser van canviar el sistema per obtenir la llista, però no van necessitar canviar l'URI.

Board of Shame - Història 2: Microsoft Netmeeting

Amb la creixent dependència d'Internet, va sorgir una idea intel·ligent que els enllaços al lloc web del fabricant es podien incrustar a les aplicacions. S'ha utilitzat i abusat molt d'això, però no podeu canviar l'URL. L'altre dia vaig provar un enllaç del client Microsoft Netmeeting 2/alguna cosa al menú Ajuda/Microsoft al menú Web/Coses gratuïtes i vaig rebre un error 404: no es va trobar cap resposta del servidor. Potser ja està arreglat...

© 1998 Tim BL

Nota històrica: a finals del segle XX, quan això es va escriure, "cool" era un epítet d'aprovació, especialment entre els joves, que indicava moda, qualitat o conveniència. Amb pressa, el camí de l'URI sovint s'escollia per "frescura" més que per a la utilitat o la durabilitat. Aquesta publicació és un intent de redirigir l'energia que hi ha darrere de la recerca de cool.

Font: www.habr.com