Autor — Sir Tim Berners-Lee, inventor del URI, URL, HTTP, HTML y la World Wide Web, actual director del W3C. El artículo fue escrito en 1998.

¿Qué URI puede considerarse "genial"?
Aquel que no cambia.
¿Cómo cambian los URI?
Los URI no cambian: son las personas quienes los modifican.

En teoría, las personas no tienen razones para cambiar los URI (o dejar de mantener documentos), pero en la práctica hay millones.

Teóricamente, el propietario nominal de un espacio de nombres de dominio realmente posee el espacio de nombres de dominio y, por ende, todos los URI en él. Aparte de la insolvencia, nada impide que el propietario del dominio mantenga ese nombre. Y teóricamente, el espacio URI bajo tu nombre de dominio está completamente bajo tu control, por lo que puedes hacerlo tan estable como desees. En gran medida, la única razón válida para que un documento desaparezca de Internet es que la empresa que poseía el nombre de dominio salió del negocio o ya no puede permitirse mantener el servidor. Entonces, ¿por qué hay tantos enlaces rotos en el mundo? En parte, es simplemente falta de previsión. Aquí hay algunas razones que se pueden escuchar:

Simplemente reorganizamos el sitio para mejorarlo.

¿Realmente crees que los antiguos URI no pueden seguir funcionando? Si es así, los elegiste muy mal. Piénsalo para que los nuevos permanezcan después del próximo rediseño.

Tenemos tanto material que no podemos seguir el rastro de lo que está obsoleto, lo que es confidencial y lo que sigue siendo relevante, así que pensamos que lo mejor era simplemente desactivar todo eso.

Solo puedo compadecerte. El W3C pasó por un período en el que teníamos que revisar cuidadosamente el material de archivo por motivos de privacidad antes de hacerlo público. La solución debe ser bien pensada de antemano: asegúrate de registrar con cada documento un público lector aceptable, la fecha de creación y, en ideal, el plazo de validez. Conserva esos metadatos.

Bueno, descubrimos que necesitábamos mover archivos...

Esta es una de las justificaciones más lamentables. Muchos no saben que los servidores web te permiten gestionar la relación entre el URI de un objeto y su ubicación real en el sistema de archivos. Imagina el espacio URI como un espacio abstracto, perfectamente organizado. Luego haz un mapeo a cualquier realidad que realmente uses para implementarlo. Después, comunícalo al servidor web. Incluso puedes escribir un fragmento de tu servidor para hacerlo correctamente.

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

¿El nombre de John estaba en el URI? No, simplemente el archivo estaba en su directorio. Bueno, está claro.

Antes usábamos un script CGI para esto, y ahora usamos un programa binario.

Hay una idea loca de que las páginas generadas por scripts deben estar ubicadas en el área "cgibin" o "cgi". Esto revela cómo ejecutas tu servidor web. Cambias el mecanismo (incluso manteniendo el contenido) y, ¡ups! — todos tus URI cambian.

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

Documentos en línea de NSF

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

La primera página para empezar a ver documentos claramente no permanecerá así en unos años. cgi-bin, oldbrowse y pl — todo esto ofrece fragmentos de información sobre cómo-lo-hacemos-ahora. Sin embargo, si usas una página para buscar un documento, obtienes primero un resultado igualmente malo:

Informe del grupo de trabajo sobre criptología y teoría de códigos

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

para la página de índice del documento, aunque el documento html mismo 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 clave para entender que sigue vigente el antiguo esquema de clasificación de documentos de 1998. Aunque en 2098 los números de documentos pueden verse diferentes, puedo imaginar que este URI aún será válido, y no obstaculizará a la NSF o cualquier otra organización que mantenga el archivo.

No pensé que las URL debieran ser permanentes — ya existían las URN.

Probablemente, este es uno de los peores efectos colaterales de discutir sobre las URN. Algunos piensan que debido a las investigaciones sobre un espacio de nombres más permanente, pueden tratar de forma negligente los enlaces rotos, ya que «las URN lo solucionarán todo». Si eres una de esas personas, permíteme decepcionarte.

La mayoría de los esquemas URN que he visto se parecen a un identificador de autoridad, seguido de una fecha y una cadena que elijas, o simplemente de una cadena que elijas. Es muy similar a un URI de HTTP. En otras palabras, si crees que tu organización podrá crear URN de larga vida, demuéstralo ahora utilizando las URN para tus URI de HTTP. No hay nada en el propio HTTP que haga que tu URI sea inestable. Solo tu organización. Crea una base de datos que vincule la URN del documento con el nombre del archivo actual y permite que el servidor web la use para la recuperación real de archivos.

Si has llegado hasta aquí, entonces si no tienes tiempo, dinero y conexiones para desarrollar algún software, puedes hacer la siguiente declaración justificante:

Queríamos, pero simplemente no tenemos las herramientas necesarias.

Esto merece compasión. Estoy completamente de acuerdo. Lo que necesitas hacer es hacer que el servidor web procese instantáneamente el URI permanente y devuelva el archivo, donde sea que esté almacenado en este momento en tu loca sistema de archivos actual. Quieres almacenar todos los URI en un archivo como verificación y mantener constantemente la base de datos actualizada. Quieres mantener las relaciones entre diferentes versiones y traducciones del mismo documento, así como mantener un registro independiente de suma de verificación para protegerte contra la corrupción de archivos por errores accidentales. Y los servidores web no vienen de serie con estas funciones. Cuando quieras crear un nuevo documento, tu editor te pedirá que establezcas un URI.

Necesitas la capacidad de modificar la propiedad, el acceso al documento, el nivel de seguridad de archivo de archivo y otros en el espacio URI sin cambiar el URI.

Todo es muy malo. Pero lo solucionaremos. En W3C utilizamos la funcionalidad Jigedit (el servidor Jigsaw para edición), que rastrea versiones, y estamos experimentando con scripts para crear documentos. Si estás desarrollando herramientas, servidores y clientes, ten en cuenta este problema.

Esta justificación también se aplica a muchas páginas de W3C, incluida esta: así que haz lo que digo y no lo que hago.

¿Por qué debería importarme esto?

Cuando cambias el URI en tu servidor, nunca puedes decir con certeza quién tendrá enlaces al antiguo URI. Pueden ser enlaces de páginas web habituales. Favoritos a tu página. El URI podría haber sido garabateado en los márgenes de una carta a un amigo.

Cuando alguien hace clic en un enlace y está roto, generalmente pierde la confianza en el propietario del servidor. También se siente decepcionado, tanto emocional como realmente, al no poder alcanzar su objetivo.

Muchas personas se quejan constantemente de enlaces rotos, y espero que el daño sea evidente. Espero que también sea evidente el daño reputacional al mantenedor del servidor donde ha desaparecido el documento.

¿Entonces, qué debo hacer? Diseñar el URI

Es deber del webmaster crear URIs que se puedan utilizar dentro de 2 años, 20 años o 200 años. Para ello se necesita reflexión, organización y determinación.

Los URIs cambian si se modifica alguna información en ellos. Es muy importante cómo los diseñas. (¿Qué, diseñar el URI? ¿Necesito diseñar el URI? Sí, deberías pensar en esto). Diseñar significa principalmente que no debe haber información alguna en el URI.

La fecha de creación del documento — la fecha en que se emite el URI — es algo que nunca cambiará. Es muy útil para separar las solicitudes que utilizan el nuevo sistema de aquellas que usan el antiguo. Es un buen punto de partida para el URI. Si hay una fecha marcada en el documento, incluso si el documento será relevante en el futuro, es un buen comienzo.

La única excepción es una página que intencionadamente es la «última» versión, 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 esta URI no necesita una fecha es que no hay razones para mantener una URI que sobrevivirá a la revista. El concepto de Money Daily desaparecerá cuando Money desaparezca. Si deseas referenciar contenido, deberías hacerlo por separado en los archivos:

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

(Se ve bien. Presupone que "money" significará lo mismo durante toda la existencia de pathfinder.com. Hay duplicación de "98" y un innecesario ".html", pero por lo demás parece un URI sólido.

Qué dejar de lado

¡Todo! Aparte de la fecha de creación, al poner cualquier información en el URI, de alguna manera te estás buscando problemas.

Nombre del autorLa autoría puede cambiar con el lanzamiento de nuevas versiones. Las personas dejan las organizaciones y transfieren cosas a otros.
TemaEs muy complicado. Siempre se ve bien al principio, pero cambia sorprendentemente rápido. Hablaré de esto con más detalle a continuación.
EstadoLos directorios del tipo 'antiguo', 'borrador', y demás, sin mencionar 'último' y 'genial', 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 constante, independientemente de su estado. Mantenga el estado fuera del nombre.
AccesoEn W3C hemos dividido el sitio en secciones para empleados, miembros y público. Suena bien, pero, por supuesto, los documentos comienzan como ideas de los empleados, se discuten con los miembros y luego se convierten en patrimonio público. Realmente es molesto si cada vez que un documento se abre para una discusión más amplia, todos los antiguos enlaces rotos se rompen. ¡Ahora pasamos a un simple código de fecha!
Extensión de archivoEs un fenómeno muy común. 'cgi', incluso '.html' cambiarán en el futuro. Quizás en 20 años no utilice HTML para esta página, pero los enlaces de hoy aún deberían funcionar. Los enlaces canónicos en el sitio de W3C no utilizan la extensión (cómo se hace).
Mecanismos de softwareEn el URI busque 'cgi', 'exec' y otros términos que griten 'mire, qué software estamos usando'. ¿Alguien quiere dedicar toda su vida a los scripts Perl CGI? ¿No? Entonces elimine la extensión .pl. Lea la guía del servidor sobre cómo hacerlo.
Nombre de disco. ¡Vamos! Pero yo he visto eso.

Así que el mejor ejemplo de nuestro sitio es simplemente

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

... un informe del protocolo de la reunión de presidentes de W3C.

Temas y clasificación por temas

Hablaré más sobre este peligro, ya que es una de esas cosas que son más difíciles de evitar. Por lo general, los temas aparecen en el URI cuando clasificas tus documentos según el trabajo que se realiza. Pero esa categorización cambiará con el tiempo. Los nombres de los dominios cambiarán. En W3C queríamos cambiar MarkUP a Markup, y luego a HTML, para reflejar el contenido real de la sección. Además, a menudo hay un espacio de nombres plano aquí. Dentro de 100 años, ¿seguro que no querrás reutilizar nada? En nuestra corta vida ya quisimos reutilizar 'Historia' y 'Hojas de estilo', por ejemplo.

Es una forma tentadora de organizar un sitio web, y realmente es una forma atractiva de organizar cualquier cosa, incluida toda la Red. Es una excelente solución a medio plazo, pero tiene serias desventajas a largo plazo.

En parte, las razones radican en la filosofía del significado. Cada término en el lenguaje es un objeto potencial de agrupación, y cada persona puede tener una diferente comprensión de lo que significa. Dado que las relaciones entre los sujetos se asemejan 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. Estas son mis observaciones generales (a menudo repetidas) sobre los peligros de la clasificación jerárquica como solución general.

De hecho, cuando usas un nombre de tema en un URI, te vinculas a alguna clasificación. Puede que en el futuro prefieras otra opción. Entonces, el URI estará sujeto a violaciones.

La razón para utilizar un dominio temático como parte del URI es que la responsabilidad por las subcategorías del espacio URI generalmente se delega, y entonces necesitas el nombre de un organismo organizacional: una división, un grupo o algo más que sea responsable de ese subsistema. Esta es la vinculación del URI a una estructura organizativa. Generalmente es segura solo cuando más adelante (a la izquierda) el URI está protegido por una fecha: 1998/pics puede significar para tu servidor 'lo que queríamos decir en 1998 por pics', y no 'lo que hicimos en 1998 con lo que ahora llamamos pics'.

No olvides el nombre de dominio

Recuerde que esto se refiere no solo a la ruta en la URI, sino también al nombre del servidor. Si tiene servidores separados para diferentes funciones, tenga en cuenta que esta división no podrá modificarse sin destruir muchos, muchos enlaces. Algunos errores clásicos como 'mire qué software estamos utilizando hoy' son los nombres de dominio "cgi.pathfinder.com", "secure", "lists.w3.org". Se crean para facilitar la administración de servidores. Independientemente de si el dominio representa alguna división en su empresa, el estado del documento, el nivel de acceso o el nivel de seguridad, tenga mucho, mucho cuidado antes de usar más de un nombre de dominio para diferentes tipos de documentos. Recuerde que puede ocultar múltiples servidores web dentro de un único servidor web visible utilizando redirección y proxy.

Sí, y también considere su nombre de dominio. No querrá que lo mencionen como jabon.com después de que cambie su línea de productos y deje de fabricar jabones (Mis disculpas a quien posea soap.com en este momento).

Conclusión

Mantener la URI durante 2, 20, 200 o incluso 2000 años no es tan sencillo como parece. Sin embargo, en toda la red, los webmasters toman decisiones que realmente complican esta tarea en el futuro. A menudo esto sucede porque utilizan herramientas cuyo objetivo es presentar el mejor sitio solo en el momento presente, y nadie ha considerado lo que sucederá con los enlaces cuando todo cambie. Sin embargo, el sentido aquí es que muchas, muchas cosas pueden cambiar y sus URIs pueden y deben permanecer iguales. Esto es posible solo si piensa en cómo las crea.

Ver también:

La diatriba de Jakob Nielsen sobre el mismo tema

Complementos

Cómo eliminar extensiones de archivos...

...de la URI en el servidor web actual basado en archivos?

Si está utilizando, por ejemplo, Apache, puede configurarlo para la coincidencia de contenido. Mantiene la extensión del archivo (por ejemplo, .png) en el archivo (por ejemplo, mydog.png), pero se puede hacer referencia a un recurso web sin él. Luego, Apache verifica el directorio en busca de todos los archivos con ese nombre y cualquier extensión, y puede elegir el mejor de un conjunto (por ejemplo, GIF y PNG). No es necesario colocar diferentes tipos de archivos en diferentes directorios; de hecho, la negociación de contenido no funcionará si lo haces.

Configura tu servidor para la negociación de contenido
Siempre haz enlaces a URI sin extensión

Los enlaces con extensiones seguirán funcionando, pero no permitirán que tu servidor elija el mejor de los formatos actualmente disponibles y futuros.

(En realidad, mydog, mydog.png y mydog.gif – son recursos web válidos, mydog – es un recurso de tipo de contenido universal, y mydog.png y mydog.gif – son recursos de tipo de contenido específico).

Por supuesto, si estás escribiendo tu propio servidor web, sería bueno usar una base de datos para vincular identificadores permanentes a su forma actual, aunque ten cuidado con el crecimiento ilimitado de la base de datos.

Pizarra de la vergüenza – Historia 1: Channel 7

Durante 1999, estuve supervisando el cierre de escuelas debido a la nieve a través de la página http://www.whdh.com/stormforce/closings.shtml. ¡No hay que esperar a que la información aparezca en la parte inferior de la pantalla del televisor! Puse un enlace en mi página de inicio. Llega la primera gran tormenta de nieve del año 2000, y reviso la página. Dice:

– Estado actual.
Actualmente, nada está cerrado. Por favor, vuelve en caso de alertas meteorológicas.

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

Puede que hayan cambiado el sistema para obtener la lista, pero no era necesario cambiar el URI.

Pizarra de la vergüenza – Historia 2: Microsoft Netmeeting

Con la creciente dependencia de Internet, surgió la inteligente idea de integrar enlaces a sitios del fabricante en las aplicaciones. Esto se usó y abusó en gran medida, pero – no se puede cambiar la URL. Literalmente hace unos días, probé un enlace del cliente Microsoft Netmeeting 2/something en el menú Ayuda/Microsoft en la web/Cosas gratis y obtuve un error 404 – respuesta no encontrada del servidor. Tal vez ya lo arreglaron...

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

Fuente: habr.com