Artículo publicado por W3C.
Traducido del artículo Cool URIs don’t change, el 02/07/2015 por Miguel Patzi para ADSIB
- ¿Qué hace tan genial a un URI?
- Un URI genial es uno que no cambia.
- ¿Qué tipo de URI cambia?
- URIs no cambian: la gente los cambia.
No hay razones en toda la teoría para que la gente cambie URIs (o dejen de mantener los documentos), pero millones de razones en la práctica.
En teoría, el propietario del nombre de dominio posee el espacio de nombre de dominio y por lo tanto todos los URIs en ella. A excepción de la insolvencia, nada impide que el propietario del nombre de dominio mantenga el nombre. Y, en teoría, el espacio URI bajo su nombre de dominio está totalmente bajo su control, por lo que puede hacer que sea tan estable como le guste. Prácticamente la única buena razón para que un documento desaparezca de la Web es que la empresa propietaria del nombre de dominio fuera a la quiebra o ya no pueda permitirse el lujo de mantener el servidor en funcionamiento. Entonces ¿por qué hay tantos enlaces caídos en el mundo? Parte de ello es simplemente por la falta de previsión. Aquí hay algunas razones que escucha por ahí:
Reorganicemos nuestra página web para que sea mejor.
¿De verdad cree que los viejos URIs no se pueden mantener en funcionamiento? Si es así, usted los eligió muy mal. Piense de nuevo, será capaz de mantenerlos después de ejecutar el próximo rediseño.
Tenemos mucho material al que no podemos seguir la pista de lo que está fuera de moda, lo que es confidencial y lo que es válido así que pensamos que será mejor si simplemente dejamos todo fuera.
Eso me puede simpatizar – W3C pasó por un período así, cuando tuvimos que tamizar cuidadosamente el material de archivo de confidencialidad antes de hacer públicos los archivos. La solución es la previsión – asegúrese de capturar todos los documentos de su distribución aceptable, su fecha de creación e idealmente su fecha de caducidad. Mantenga estos metadatos.
Bueno, nos dimos cuenta de que teníamos que mover los archivos…
Esta es una de las excusas más frívola. Mucha gente no sabe que los servidores como Apache te dan un gran control sobre una relación flexible entre la URI de un objeto y la ubicación de un archivo que representa lo que realmente es en un sistema de archivos. Piense en el espacio URI como un espacio abstracto, perfectamente organizado. Luego, haga un mapeo a cualquier realidad que utilice actualmente para implementarlo. Entonces, dígale a su servidor. Puede incluso escribir pedazos en su servidor para que lo haga.
John no mantiene ese archivo más, Jane lo hace.
Lo que sea que esa URI estuviera haciendo con el nombre de John? Fue en su directorio?.
Solíamos utilizar un script cgi para esto y ahora usamos un programa binario.
Hay una loca idea de que las páginas producidas por scripts tienen que ser ubicados en un «cgibin» o área «cgi». Esto está exponiendo el mecanismo de cómo se ejecuta el servidor. Cambie el mecanismo (manteniendo el contenido de la misma) y ¡ups! – todas sus URIs cambian.
Por ejemplo, tomemos la Fundación Nacional de la Ciencia:
Documentos Online de NFS
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl
la página principal para empezar a buscar documentos, claramente no va a ser algo en que confiar para estar allí en unos pocos años. «Cgi-bin» y «oldbrowse» y «.pl» apuntan a los bits, como lo hacemos ahora. Por el contrario, si utiliza la página para encontrar un documento, se obtiene primero una igualmente mal
Informe del Grupo de Trabajo sobre Criptología y Teoría de Codificación
http://www.nsf.gov/cgi-bin/getpub?nsf9814
para la página índice del documento, pero el documento HTML en sí por el contrario es mucho mejor:
http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
En cuanto a éste, la cabecéra de «pubs/1998» va a dar en el futuro servicio de archivo un buen indicio de que el viejo esquema de clasificación de documentos de 1998 está en progreso. Aunque en 2098 los números de documento podrían lucir diferente, Puedo imaginar este URI aún siendo válido, y el NSF o lo que sea que lleva en el archivo no estar en absoluto avergonzado de ello.
No creo que las URLs tengan que ser persistentes – esas fueron URNs.
Este es probablemente uno de los peores efectos secundarios de las discusiones sobre URN. Algunos parecen pensar que debido a que hay una investigación acerca de los espacios de nombre, serán más persistentes, eso puede ser tan laxo en enlaces caídos tanto así que piensan que «URNs arreglarán todo eso». Si usted es una de estas personas, entonces me permitirá desilusionarlo.
La mayoría de los esquemas URN que he visto lucen como un ID de autoridad seguido por cualquier fecha y una cadena que usted elije, o simplemente una cadena que usted elije. Esto se parece mucho a un HTTP URI. En otras palabras, si usted piensa que su organización será capaz de crear URNs que durarán, entonces pruébelo, haciéndolo ahora y utilizándolos para sus URIs HTTP. No hay nada acerca de HTTP que haga a su URI inestable. Es su organización. Hacer una base de datos que mapea un documento URN a nombre del archivo actual, y deja que el servidor web use eso para recuperar archivos.
Si has llegado a este punto, y a menos que usted tenga el tiempo, el dinero y los contactos para conseguir un poco de diseño de software hecho, entonces usted podría reclamar la siguiente excusa:
Nos gustaría, pero simplemente no tenemos las herramientas adecuadas.
Ahora si me puede simpatizar. Estoy totalmente de acuerdo. Lo que hay que hacer es tener el servidor web con un URI persistente en un instante y restablecer el archivo, donde sea que su loco sistema de archivos actual lo tenga guardado en ese momento. ¿Le gustaría ser capaz de almacenar la URI en el archivo como un cheque, y constantemente mantener la base de datos en sintonía con la actualidad. Desería almacenar las relaciones entre las diferentes versiones y traducciones de un mismo documento, y además le gustaría mantener un registro independiente de la suma de control para proporcionar una protección contra la corrupción de archivos por error accidental. Y simplemente los servidores web no salen de la caja con estas características. Cuando se desea crear un nuevo documento, su editor pregunta a un URI en lugar de pedirselo a usted.
¡Necesita ser capaz de cambiar cosas como la propiedad, el acceso, el nivel de seguridad a nivel de archivo, y así sucesivamente, de un documento en el espacio URI sin cambiar la URI.
Demasiado malo. Pero llegaremos allí. En W3C usamos funcionalidad Jigedit (servidor Jigsaw utilizado para la edición), que hace un seguimiento de versiones, y estamos experimentando con scripts de creación de documentos. Si usted hace las herramientas, servidores y clientes, tome nota!
Esta es una razón excepcional, que se aplica por ejemplo a muchas páginas del W3C incluyendo éste: así que haga lo que digo, no lo que yo hago.
Por qué debería importarme?
Cuando cambia un URI en su servidor, no puede estar completamente seguro de quien tendrá los enlaces a la URI anterior. Podría tener enlaces hechos desde páginas web regulares. Podrían tener marcada su página. Podrían tener garabateado la URI en el margen de una carta a un amigo.
Cuando alguien sigue un enlace y se rompe, por lo general, pierden confianza en el propietario del servidor. También se sienten frustrados – emocional y prácticamente por no cumplir su objetivo.
Bastante gente se queja acerca de enlaces caídos y el daño es evidente. También es evidente el daño a la reputación del responsable del servidor cuyo documento desapareció.
Entonces, qué debería hacer? Diseñar URIs
Es el deber de un Webmaster asignar URIs que usted será capaz de mantener por 2 años, 20 años o 200 años. Para esto necesita el pensamiento, la organización y el compromiso.
URIs cambian cuando hay alguna información que cambia en ellos. Es fundamental cómo diseñarlos. (Qué, diseñar un URI? Tengo que diseñar URIs? Sí, usted tiene que pensar en ello). Diseñar, mayormente, significa dejar información fuera.
La fecha de creación del documento – la fecha de la URI es emitida – es una cosa que no cambiará. Es muy útil para la separación de las solicitudes que utilizan un nuevo sistema de aquellos que utilizan un sistema antiguo. Esa es una cosa con la que es bueno comenzar un URI. Si un documento esta de alguna manera fechada, incluso eso será de interés para las generaciones, entonces la fecha es un buen arranque.
La única excepción es una página que esté deliberadamente «reciente», por ejemplo, toda la organización o una gran parte de ella.
http://www.pathfinder.com/money/moneydaily/latest/
es la más reciente «Money daily» la columna en la revista «Money». La razón principal para no necesitar la fecha en este URI es que no hay ninguna razón para la persistencia de la URI para sobrevivir a la revista. El concepto de «today’s Money» se desvanece si Money sale de la producción. Si quiere enlazar el contenido, debería enlazarlo donde aparece separádamente en los archivos como
http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html
(Se ve bien. Asume que «money» significará lo mismo durante toda la vida de pathfinder.com. Hay una duplicación de los «98» y un «.html» que no es necesario pero por lo demás esto parece una URI fuerte) .
Que dejar de lado
¡Todo! Después de la fecha de creación, poner alguna información en el nombre es preguntar por problemas de una manera u otra.
- Nombre de los autores – autoría puede cambiar con las nuevas versiones. Las personas dejan las organizaciones y entregan su autoría.
- Materia. Esto es un truco. Siempre parece bueno en el momento pero cambian sorpresivamente. Debato sobre esto más abajo.
- Estado – directorios «viejos» y «borradores» y parecidos, por no hablar de «lo más reciente» y «lo genial» apareceran en todo los sistemas de archivos.
- Documentos cambian de estado – o no habría ningún punto en la elaboración de borradores. La última versión de un documento necesita un identificador persistente cualquiera que sea su estado. Excluyendo el estado de el nombre.
- Acceso. En W3C dividimos el sitio en «Acceso de equipo», «Acceso de miembro» y «Acceso público». Suena bien, pero por supuesto, los documentos inician como un conjunto de ideas, son discutidos con los miembros, y luego salen al público. Una pena en verdad, si cada vez que algún documento es abierto para una discusión más amplia, todos los viejos enlaces a fracasar! Estamos cambiando para tener un código sencillo de fecha.
- Extensión del archivo. Esto es algo muy común «.cgi», incluso «.html» es algo que cambiará. Usted no puede estar utilizando HTML para esa página dentro de 20 años, pero es posible que desee enlaces de hoy que todavía sean válidas en un futuro. La forma canónica de hacer enlaces al sitio W3C no utiliza la extensión. ([¿cómo?])(http://www.w3.org/Provider/Style/URI.html#remove)
- Mecanismos de software. Busque «cgi», «exec» y otro obsequio «Mire que software estamos utilizando» bits en los URIs. ¿Alguien quiere comprometerse con el uso de scripts cgi, perl toda su vida? No? Corte el .pl. Lea el manual del servidor para saber como hacerlo.
- Nombre de Disco – Dame un descanso! Pero ya lo he visto.
Así un ejemplo mejor de nuestro sitio es simplemente
http://www.w3.org/1998/12/01/chairs
un reporte de minutos de una reunión de la gente de W3C.
Temas y clasificación por materia
Voy a entrar en este peligro con más detalle, ya que es una de las cosas más difíciles de evitar. Por lo general, los temas terminan en URIs cuando usted clasifica sus documentos de acuerdo a un fallo del trabajo que está haciendo. Ese fallo cambiará. Nombres para las áreas que cambiarán. En W3C queríamos cambiar «MarkUp» a «Markup» y luego a «HTML» para reflejar el contenido actual de la sección. Además, tenga en cuenta que esto es a menudo un espacio de nombres plano. En 100 años ¿Seguro que no querrá reutilizar cualquier cosa? Queríamos reutilizar «Historia» y «Hojas de estilo», por ejemplo en nuestra corta vida.
Esta es una manera tentadora de organizar un sitio web – y de hecho una manera tentadora de organizar cualquier cosa, incluyendo toda la web. Es una gran solución a mediano plazo, pero tiene serios inconvenientes en el largo plazo.
Parte de las razones de esta mentira está en la filosofía del sentido. Cada término en el lenguaje es materia para una agrupación potencial, y cada persona puede tener una idea diferente de lo que significa. Debido a que las relaciones entre los sujetos son como en la web en lugar de en forma de árbol, incluso para las personas que están de acuerdo en una web puede elegir una representación de árbol diferente. Estos son mis (repetidos) comentarios generales sobre los peligros de la clasificación jerárquica como una solución general.
Efectivamente, cuando se utiliza un nombre de tema en un URI que usted mismo está enlazando a alguna clasificación. En el futuro, es posible que prefiera uno diferente. Entonces, el URI será responsable de eso.
Una razón para usar un área temática como parte de la URI es que la responsabilidad por sub-partes de un espacio URI es típicamente delegado, y entonces usted necesita un nombre para el cuerpo de la organización – la subdivisión, grupo o lo que sea – tiene la responsabilidad de ese sub-espacio. Esto significa unir sus URIs a la estructura organizacional. Por lo general está seguro sólo cuando está protegido por una fecha en la URI (a la izquierda de la misma): 1998/fotos puede ser tomada para significar en su servidor «lo que significaba en 1998 para fotos«, en lugar de «lo que en 1998 haciamos con lo que ahoranos referimos como fotos «.
No olvide el nombre de dominio.
Recuerde que esto se aplica no sólo a la parte «ruta» de una URI si no al nombre del servidor. Si dispone de servidores separados para algunas de sus cosas, recuerde que esa división será imposible de cambiar sin destruir muchos muchos enlaces. Algo clásico «se ve en el software que estamos utilizando hoy en día» los nombres de dominio son «cgi.pathfinder.com», «secure», «lists.w3.org». Están hechas para que la administración de los servidores sea más fácil. Si representa divisiones en su empresa, o estado de documentos, o el nivel de acceso, o el nivel de seguridad, sea muy, muy cuidadoso antes de usar más de un nombre de dominio para más de un tipo de documento. recuerde que usted puede ocultar muchos servidores web dentro de un servidor web aparente utilizando redirección y proxy.
Ah, y piense en su nombre de dominio. Si su nombre no es jabón, deseará que ser referido como «jabón.com», incluso si está activada su línea de productos a otra cosa. (Con disculpas a todo el que posee jabón.com por el momento).
Conclusión
Manter las URIs todavía será alrededor de 2, 20, 200 o incluso 2.000 años que claramente no es tan simple como suena. Sin embargo, en todo la web, los webmasters están tomando decisiones que harán que sea muy difícil para ellos mismos en el futuro. A menudo, esto se debe a que están utilizando herramientas cuyas tareas son parecidas a presentar el mejor sitio en el momento, y nadie ha evaluado lo que sucederá con los enlaces cuando las cosas cambian. El mensaje aquí es, sin embargo, que muchas, muchas cosas pueden cambiar y sus URIs pueden y deben permanecer igual. Sólo pueden si piensan en cómo diseñarlos.
Ver también:
(De nuevo a Etiqueta para los administradores de servidores , a la Estructura de su trabajo)
Nota
¿Cómo puedo eliminar la extensión de los archivos…
…de mis URIs en un servidor web práctico basado en archivos?
Si está utilizando, por ejemplo, Apache, puede configurarlo para hacer la negociación de contenido. Usted mantiene la extensión de archivo (como .png) en el archivo (por ejemplo miperro.png ), pero se refiere al recurso web sin él. Apache comprueba el directorio para todos los archivos con ese nombre y cualquier extensión, y también puede escoger el mejor de un conjunto (por ejemplo, GIF y PNG). (Usted no tiene que poner diferentes tipos de archivos en directorios diferentes, de hecho, la negociación de contenido no funcionará si lo hace.)
- Configure su servidor para hacer la negociación de contenido
- Hacer referencia siempre a la URI sin la extensión
Las referencias que sí tienen la extensión seguirán funcionando, pero no permitirán a su servidor seleccionar el mejor de los formatos disponibles actualmente ni en futuros formatos.
(De hecho, miperro , miperro.png y miperro.gif son recursos web válidos. miperro es contenido de tipo genérico y miperro.png y miperro.gif son contenido de tipo específico.)
Por supuesto, si usted está construyendo su propio servidor, utilizando una base de datos para relacionar identificadores persistentes a su forma actual es una idea muy limpia — aunque cuidado con el crecimiento sin límites de su base de datos.
Salón de la llama – historia 1: Canal 7
Durante 1999, http://www.whdh.com/stormforce/closings.shtml era una página que encontré documentación sobre el cierre de escuelas debido a la nieve. Una alternativa a la espera para que ellos se desplacen más allá del fondo de la pantalla de la TV! Puse un puntero desde mi página de inicio. Ven la primera gran tormenta de 2000, y compruebo la página. Dice,
«Cierres como:
Actualmente no hay cierres en efecto. Por favor, vuelva cuando el tiempo se lo ordene»
No puede ser una gran tormenta. Divertido, a la fecha no se encuentra. Pero entonces si voy a la página principal del sitio, hay un gran botón «cierre de escuelas», que me lleva a http://www.whdh.com/stormforce/que tiene una lista de muchas escuelas cerradas.
Bueno, tal vez cambiaron el sistema que tiene los cierres de la lista definitiva – pero que no era necesario cambiar la URI.
Salón de la llama – historia 2: Microsoft NetMeeting
Uno de los sofisticados que venía con una creciente dependencia en la web eran esas aplicaciones que pudieron haber incorporado enlaces de regreso al sitio web del fabricante. Esto ha sido usado y abusado en gran medida, pero – usted tiene que mantener la URL igual. Justo el otro día probé un enlace desde Netmeeting 2 de Microsoft y bajo un menú «Ayuda/Microsoft en las cosas de Web/Free» conseguí un Error 404 – No se ha encontrado respuesta del servidor. Probablemente la han arreglado por ahora …
(C) 1998 Tim BL
Nota histórica: A finales del siglo 20, cuando esto fue escrito, «genial» era un epíteto de aprobación en particular entre los jóvenes, lo que indica tendencia, calidad o idoneidad. En la carrera por la aceptación en nuestro territorio, DNS implicó la elección del nombre de dominio y la ruta URI se dirigió a veces más hacia la «frialdad» aparente que hacia la utilidad o la longevidad. Esta nota es un intento de redirigir la energía detrás de la búsqueda de la frescura.