Autor: Sir Tim Berners-Lee, inventor de URI, URL, HTTP, HTML y la World Wide Web, y actual director del W3C. Artículo escrito en 1998.

¿Qué URI se considera "cool"?
Uno que no cambia.
¿Cómo se cambian los URI?
Los URI no cambian: la gente los cambia.

En teoría, no hay razón para que las personas cambien los URI (o dejen de respaldar los documentos), pero en la práctica hay millones de ellos.

En teoría, el propietario nominal de un espacio de nombres de dominio en realidad es propietario del espacio de nombres de dominio y, por lo tanto, de todos los URI que contiene. Aparte de la insolvencia, nada impide al propietario de un nombre de dominio conservarlo. Y, en teoría, el espacio URI bajo su nombre de dominio está completamente bajo su control, por lo que puede hacerlo tan estable como desee. Prácticamente la única buena razón para que un documento desaparezca de Internet es que la empresa propietaria del nombre de dominio cerró o ya no puede permitirse mantener el servidor en funcionamiento. Entonces, ¿por qué faltan tantos eslabones en el mundo? Algo de esto es simplemente una falta de previsión. Aquí hay algunas razones que podría escuchar:

Acabamos de reorganizar el sitio para mejorarlo.

¿De verdad crees que los antiguos URI ya no pueden funcionar? Si es así, entonces los elegiste muy mal. Considere conservar los nuevos para el próximo rediseño.

Tenemos tantas cosas que no podemos realizar un seguimiento de lo que está desactualizado, lo que es confidencial y lo que sigue siendo relevante, por lo que pensamos que sería mejor desactivarlo todo.

Sólo puedo simpatizar. El W3C pasó por un período en el que tuvimos que examinar cuidadosamente los materiales de archivo para garantizar su confidencialidad antes de hacerlos públicos. La decisión debe pensarse con anticipación: asegúrese de registrar con cada documento el número de lectores aceptable, la fecha de creación e, idealmente, la fecha de vencimiento. Guarde estos metadatos.

Bueno, descubrimos que necesitamos mover archivos...

Ésta es una de las excusas más patéticas. Mucha gente no sabe que los servidores web le permiten controlar la relación entre el URI de un objeto y su ubicación real en el sistema de archivos. Piense en el espacio URI como un espacio abstracto, perfectamente organizado. Luego haz un mapeo de cualquier realidad que realmente uses para realizarla. Luego informe esto al servidor web. Incluso puedes escribir tu propio fragmento de servidor para hacerlo bien.

John ya no mantiene este archivo, Jane ahora lo hace.

¿Estaba el nombre de John en el URI? No, ¿el archivo estaba solo en su directorio? Bueno esta bien.

Anteriormente usábamos un script CGI para esto, pero ahora usamos un programa binario.

Existe la loca idea de que las páginas creadas mediante scripts deben ubicarse en el área "cgibin" o "cgi". Esto expone la mecánica de cómo ejecuta su servidor web. Cambia el mecanismo (incluso mientras guarda contenido) y, ¡vaya!, todos sus URI cambian.

Tomemos como ejemplo la Fundación Nacional de Ciencias (NSF):

Documentos en línea NSF

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

Es evidente que la primera página para empezar a ver documentos no seguirá siendo la misma dentro de unos años. cgi-bin, oldbrowse и pl - todo esto proporciona fragmentos de información sobre cómo-lo-hacemos-ahora. Si utilizas la página para buscar un documento, el primer resultado que obtienes es igualmente malo:

Informe del Grupo de Trabajo sobre Criptología y Teoría de la Codificación

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

para la página de índice del documento, aunque el documento html en sí se ve mucho mejor:

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

Aquí el encabezado pubs/1998 dará a cualquier servicio de archivo futuro una buena pista de que el antiguo esquema de clasificación de documentos de 1998 está vigente. Aunque los números de los documentos pueden verse diferentes en 2098, me imagino que este URI seguiría siendo válido y no interferiría con NSF ni con ninguna otra organización que mantuviera el archivo.

No pensé que las URL tuvieran que ser persistentes: había URN.

Este es probablemente uno de los peores efectos secundarios del debate sobre la URN. Algunas personas piensan que debido a la investigación sobre un espacio de nombres más permanente, podrían ser descuidados con los enlaces colgantes porque "las URN arreglarán todo eso". Si eres una de estas personas, déjame decepcionarte.

La mayoría de los esquemas de URN que he visto parecen un identificador de autoridad seguido de una fecha y una cadena que usted selecciona, o simplemente una cadena que usted selecciona. Esto es muy similar a un URI HTTP. En otras palabras, si cree que su organización será capaz de crear URN de larga duración, pruébelo ahora usándolos para sus URI HTTP. No hay nada en HTTP en sí que haga que su URI sea inestable. Sólo tu organización. Cree una base de datos que asigne la URN del documento al nombre del archivo actual y deje que el servidor web la use para recuperar los archivos.

Si has llegado a este punto, si no tienes el tiempo, el dinero y las conexiones para desarrollar algún software, entonces puedes poner la siguiente excusa:

Queríamos hacerlo, pero simplemente no tenemos las herramientas adecuadas.

Pero puedes simpatizar con esto. Estoy completamente de acuerdo. Lo que debe hacer es forzar al servidor web a analizar instantáneamente el URI persistente y devolver el archivo donde esté almacenado actualmente en su loco sistema de archivos actual. Desea almacenar todos los URI en un archivo como verificación y mantener la base de datos actualizada en todo momento. Desea preservar la relación entre diferentes versiones y traducciones del mismo documento y también mantener un registro de suma de verificación independiente para garantizar que el archivo no se dañe por un error accidental. Y los servidores web simplemente no vienen con estas características. Cuando desea crear un documento nuevo, su editor le pide que especifique un URI.

Debe poder cambiar la propiedad, el acceso a los documentos, la seguridad del nivel de archivo, etc. en el espacio URI sin cambiar el URI.

Es una lástima. Pero corregiremos la situación. En el W3C, utilizamos la funcionalidad Jigedit (servidor de edición de Jigsaw) que rastrea las versiones y experimentamos con scripts de creación de documentos. Si desarrolla herramientas, servidores y clientes, ¡preste atención a este problema!

Esta excusa también se aplica a muchas páginas del W3C, incluida ésta: haz lo que digo, no lo que hago.

¿Por qué debería importarme?

Cuando cambia el URI en su servidor, nunca podrá saber completamente quién tendrá enlaces al URI anterior. Estos pueden ser enlaces de páginas web normales. Añade tu página a favoritos. Es posible que la URI haya sido garabateada en los márgenes de una carta dirigida a un amigo.

Cuando alguien sigue un enlace y éste se rompe, normalmente pierde la confianza en el propietario del servidor. También se siente frustrado, tanto emocional como físicamente, por no poder lograr su objetivo.

Mucha gente se queja todo el tiempo de enlaces rotos y espero que el daño sea evidente. Espero que el daño a la reputación del responsable del servidor donde desapareció el documento también sea evidente.

¿Entonces qué debo hacer? diseño de URI

Es responsabilidad del webmaster asignar URI que puedan usarse en 2 años, en 20 años, en 200 años. Esto requiere consideración, organización y determinación.

Los URI cambian si cambia alguna información en ellos. Cómo los diseñas es muy importante. (¿Qué, diseño de URI? ¿Necesito diseñar el URI? Sí, deberías pensar en eso). Básicamente, diseñar significa omitir cualquier información en el URI.

La fecha en que se creó el documento (la fecha en que se emitió el URI) es algo que nunca cambiará. Es muy útil para separar consultas que utilizan el nuevo sistema de aquellas que utilizan el antiguo. Este es un buen lugar para comenzar con un URI. Si un documento tiene fecha, incluso si será relevante en el futuro, entonces es un buen comienzo.

La única excepción es una página que es intencionadamente la versión "más reciente", por ejemplo para toda la organización o una gran parte de ella.

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

Esta es la última columna de Money Daily en la revista Money. La razón principal por la que no es necesaria una fecha en este URI es que no hay motivo para almacenar el URI que sobrevivirá al registro. El concepto de Money Daily desaparecerá cuando desaparezca Money. Si desea vincular el contenido, debe vincularlo por separado en los archivos:

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

(Se ve bien. Se supone que "dinero" significará lo mismo durante toda la vida de pathfinder.com. Hay un "98" duplicado y un ".html" innecesario, pero por lo demás parece un URI fuerte.

que dejar de lado

¡Todo! Aparte de la fecha de creación, poner cualquier información en el URI genera problemas de una forma u otra.

• Nombre del autor. La autoría puede cambiar a medida que haya nuevas versiones disponibles. La gente abandona las organizaciones y pasa cosas a otros.
• Asunto. Es muy difícil. Al principio siempre parece bueno, pero cambia sorprendentemente rápido. Hablaré más sobre esto a continuación.
• Estado. Directorios como "antiguo", "borrador", etc., sin mencionar "más reciente" y "cool", aparecen en todos los sistemas de archivos. Los documentos cambian de estado; de lo contrario, no tendría sentido crear borradores. La última versión de un documento necesita un identificador persistente, independientemente de su estado. Mantenga el estado fuera del nombre.
• Acceso. En W3C, hemos dividido el sitio en secciones para empleados, miembros y público. Esto suena bien, pero, por supuesto, los documentos comienzan como ideas del equipo del personal, se discuten con los miembros y luego se vuelven de conocimiento público. ¡Sería realmente una lástima que cada vez que se abre un documento para una discusión más amplia, todos los enlaces antiguos se rompan! Ahora pasamos a un código de fecha simple.
• Extensión de archivo. Un fenómeno muy común. "cgi", incluso ".html" cambiarán en el futuro. Es posible que no utilice HTML para esta página dentro de 20 años, pero los enlaces actuales a ella aún deberían funcionar. Los enlaces canónicos en el sitio W3C no utilizan la extensión (cómo está hecho).
• Mecanismos de software. En el URI, busque "cgi", "exec" y otros términos que griten "mira qué software estamos usando". ¿Alguien quiere pasar toda su vida escribiendo guiones CGI en Perl? ¿No? Luego elimine la extensión .pl. Lea el manual del servidor sobre cómo hacer esto.
• Nombre del disco. ¡Vamos! Pero he visto esto.

Así que el mejor ejemplo de nuestro sitio es simplemente

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

... informe sobre las actas de la reunión de presidentes del W3C.

Temas y clasificación por tema

Entraré más en detalle sobre este peligro, ya que es una de esas cosas que más difíciles de evitar. Normalmente, los temas terminan en URI cuando clasifica sus documentos según el trabajo que realizan. Pero este desglose cambiará con el tiempo. Los nombres de las áreas cambiarán. En el W3C queríamos cambiar MarkUP a Markup y luego a HTML para reflejar el contenido real de la sección. Además, suele haber un espacio de nombres plano. ¿Estás seguro de que dentro de 100 años no querrás reutilizar nada? En nuestra corta vida ya hemos querido reutilizar el “Historial” y las “Hojas de estilo” por ejemplo.

Es una forma tentadora de organizar un sitio web y una forma realmente tentadora de organizar cualquier cosa, incluida toda la Web. Se trata de una gran solución a medio plazo, pero tiene graves deficiencias a largo plazo.

Parte de la razón reside en la filosofía del significado. Cada término de un idioma es un objetivo potencial de agrupación y cada persona puede tener una idea diferente de lo que significa. Dado que las relaciones entre entidades se parecen más a una red que a un árbol, incluso aquellos que están de acuerdo con la red pueden elegir una representación diferente del árbol. Éstas son mis (a menudo repetidas) observaciones generales sobre los peligros de la clasificación jerárquica como solución general.

De hecho, cuando utilizas el nombre de un tema en un URI, te estás comprometiendo con algún tipo de clasificación. Quizás en el futuro prefieras una opción diferente. El URI será entonces susceptible de violación.

La razón para utilizar un área temática como parte de un URI es que la responsabilidad de las subsecciones del espacio URI generalmente se delega, y luego se necesita el nombre del organismo organizacional (departamento, grupo o lo que sea) que es responsable de ese subespacio. Este es un URI vinculado a una estructura organizativa. Por lo general, solo es seguro si el URI más alejado (izquierdo) está protegido por una fecha: 1998/pics podría significar para su servidor "lo que queríamos decir en 1998 con fotografías" en lugar de "lo que hicimos en 1998 con lo que ahora llamamos fotografías".

No olvides el nombre del dominio.

Recuerde que esto se aplica no sólo a la ruta en el URI, sino también al nombre del servidor. Si tiene servidores separados para diferentes cosas, recuerde que será imposible cambiar esta división sin destruir muchos, muchos enlaces. Algunos errores clásicos de "mira el software que utilizamos hoy" son los nombres de dominio "cgi.pathfinder.com", "secure", "lists.w3.org". Están diseñados para facilitar la administración del servidor. Independientemente de si un dominio representa una división de su empresa, el estado de un documento, un nivel de acceso o un nivel de seguridad, tenga mucho, mucho cuidado antes de utilizar más de un nombre de dominio para varios tipos de documentos. Recuerde que puede ocultar varios servidores web dentro de un único servidor web visible mediante la redirección y el proxy.

Ah, y piensa también en tu nombre de dominio. No querrás que te llamen Soap.com después de cambiar de línea de productos y dejar de fabricar jabón (lo siento por el propietario de Soap.com en este momento).

Conclusión

Preservar un URI durante 2, 20, 200 o incluso 2000 años obviamente no es tan fácil como parece. Sin embargo, en Internet, los webmasters están tomando decisiones que les dificultan mucho esta tarea en el futuro. A menudo esto se debe a que utilizan herramientas cuyo trabajo es presentar el mejor sitio sólo en el momento, y nadie ha evaluado qué pasará con los enlaces cuando todo cambie. Sin embargo, el punto aquí es que muchas, muchas cosas pueden cambiar y sus URI pueden y deben seguir siendo los mismos. Esto sólo es posible cuando piensas en cómo los creas.

Ver también:

• La diatriba de Jakob Nielsen sobre el mismo tema

Adiciones

Cómo eliminar extensiones de archivos...

...¿desde un URI en el servidor web actual basado en archivos?

Si usa Apache, por ejemplo, puede configurarlo para negociar contenido. Guarde la extensión del archivo (por ejemplo, .png) en un archivo (por ejemplo, miperro.png), pero puedes vincular a un recurso web sin él. Luego, Apache comprueba el directorio en busca de todos los archivos con ese nombre y cualquier extensión, y puede elegir el mejor del conjunto (por ejemplo, GIF y PNG). Y no es necesario colocar diferentes tipos de archivos en diferentes directorios; de hecho, la coincidencia de contenido no funcionará si lo hace.

• Configure su servidor para negociar contenido
• Vincular siempre a URI sin extensión

Los enlaces con extensiones seguirán funcionando, pero impedirán que su servidor elija el mejor formato disponible actualmente y en el futuro.

(De hecho, mydog, mydog.png и mydog.gif — recursos web válidos, mydog es un recurso de tipo de contenido universal, y mydog.png и mydog.gif — recursos de un tipo de contenido específico).

Por supuesto, si está escribiendo su propio servidor web, es una buena idea utilizar una base de datos para vincular los identificadores persistentes a su forma actual, aunque tenga cuidado con el crecimiento ilimitado de la base de datos.

El Tablero de la Vergüenza - Historia 1: Canal 7

Durante 1999, rastreé los cierres de escuelas debido a la nieve en la página http://www.whdh.com/stormforce/closings.shtml. ¡No esperes a que la información aparezca en la parte inferior de la pantalla del televisor! Lo vinculé desde mi página de inicio. Llega la primera gran tormenta de nieve del año 2000 y reviso la página. Está escrito allí:,

- A partir de.
Actualmente no hay nada cerrado. Por favor regrese en caso de advertencias climáticas.

No puede ser una tormenta tan fuerte. Es curioso que falte la fecha. Pero si va a la página principal del sitio, habrá un botón grande "Escuelas cerradas", que conduce a la página http://www.whdh.com/stormforce/ con una larga lista de escuelas cerradas.

Tal vez cambiaron el sistema para obtener la lista, pero no necesitaron cambiar el URI.

Board of Shame - Historia 2: Microsoft Netmeeting

Con la creciente dependencia de Internet, surgió la inteligente idea de integrar enlaces al sitio web del fabricante en las aplicaciones. Se ha usado y abusado mucho de esto, pero no se puede cambiar la URL. El otro día probé un enlace del cliente Microsoft Netmeeting 2/algo en el menú Ayuda/Microsoft en la Web/Cosas gratis y recibí un error 404: no se encontró respuesta del servidor. Quizás ya esté arreglado...

© 1998 Tim BL

Nota histórica: A finales del siglo XX, cuando se escribió esto, "genial" era un epíteto de aprobación, especialmente entre los jóvenes, que indicaba moda, calidad o idoneidad. A toda prisa, la ruta URI a menudo se elegía por su "frescura" en lugar de su utilidad o durabilidad. Esta publicación es un intento de redirigir la energía detrás de la búsqueda de lo cool.

Fuente: habr.com