{"id":89253,"date":"2020-07-21T01:42:24","date_gmt":"2020-07-20T23:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya"},"modified":"2020-07-21T01:42:24","modified_gmt":"2020-07-20T23:42:24","slug":"krutye-uri-ne-izmenyayutsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya","title":{"rendered":"Las URI geniales no cambian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Autor \u2014 Sir Tim Berners-Lee, inventor del URI, URL, HTTP, HTML y la World Wide Web, actual director del W3C. El art\u00edculo fue escrito en 1998. <\/p>\n

\u00bfQu\u00e9 URI puede considerarse \"genial\"?
\nAquel que no cambia.
\n\u00bfC\u00f3mo cambian los URI?
\nLos URI no cambian: son las personas quienes los modifican.<\/i> <\/p>\n

En teor\u00eda, las personas no tienen razones para cambiar los URI (o dejar de mantener documentos), pero en la pr\u00e1ctica hay millones.<\/p>\n

Te\u00f3ricamente, 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 \u00e9l. Aparte de la insolvencia, nada impide que el propietario del dominio mantenga ese nombre. Y te\u00f3ricamente, el espacio URI bajo tu nombre de dominio est\u00e1 completamente bajo tu control, por lo que puedes hacerlo tan estable como desees. En gran medida, la \u00fanica raz\u00f3n v\u00e1lida para que un documento desaparezca de Internet es que la empresa que pose\u00eda el nombre de dominio sali\u00f3 del negocio o ya no puede permitirse mantener el servidor. Entonces, \u00bfpor qu\u00e9 hay tantos enlaces rotos en el mundo? En parte, es simplemente falta de previsi\u00f3n. Aqu\u00ed hay algunas razones que se pueden escuchar:
\n<\/a><\/noindex><\/p>\n

Simplemente reorganizamos el sitio para mejorarlo.<\/h4>\n

\n\u00bfRealmente crees que los antiguos URI no pueden seguir funcionando? Si es as\u00ed, los elegiste muy mal. Pi\u00e9nsalo para que los nuevos permanezcan despu\u00e9s del pr\u00f3ximo redise\u00f1o.<\/p>\n

Tenemos tanto material que no podemos seguir el rastro de lo que est\u00e1 obsoleto, lo que es confidencial y lo que sigue siendo relevante, as\u00ed que pensamos que lo mejor era simplemente desactivar todo eso.<\/h4>\n

\nSolo puedo compadecerte. El W3C pas\u00f3 por un per\u00edodo en el que ten\u00edamos que revisar cuidadosamente el material de archivo por motivos de privacidad antes de hacerlo p\u00fablico. La soluci\u00f3n debe ser bien pensada de antemano: aseg\u00farate de registrar con cada documento un p\u00fablico lector aceptable, la fecha de creaci\u00f3n y, en ideal, el plazo de validez. Conserva esos metadatos.<\/p>\n

Bueno, hemos descubierto que es necesario mover los archivos\u2026<\/h4>\n

\nEsta es una de las justificaciones m\u00e1s lamentables. Muchos no saben que los servidores web te permiten gestionar la relaci\u00f3n entre el URI de un objeto y su ubicaci\u00f3n 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\u00e9s, comun\u00edcalo al servidor web. Incluso puedes escribir un fragmento de tu servidor para hacerlo correctamente.<\/p>\n

John ya no mantiene este archivo, ahora lo hace Jane.<\/p>\n

\u00bfEl nombre de John estaba en el URI? No, simplemente el archivo estaba en su directorio. Bueno, est\u00e1 claro.<\/p>\n

Antes us\u00e1bamos un script CGI para esto, y ahora usamos un programa binario.<\/h4>\n

\nExiste una idea loca que dice que las p\u00e1ginas creadas por scripts deber\u00edan estar ubicadas en el \u00e1rea \"cgibin\" o \"cgi\". Esto revela c\u00f3mo ejecutas tu servidor web. Cambias el mecanismo (incluso manteniendo el contenido), y ups \u2014 todos tus URI cambian.<\/p>\n

Tomemos, por ejemplo, la Fundaci\u00f3n Nacional de Ciencias (NSF):<\/p>\n

Documentos en l\u00ednea de NSF<\/p>\n

http:\/\/www.nsf.gov\/cgi-bin\/pubsys\/browser\/odbrowse.pl<\/pre>\n
\nLa primera p\u00e1gina para empezar a ver documentos claramente no permanecer\u00e1 as\u00ed en unos a\u00f1os. cgi-bin<\/code>, oldbrowse<\/code> y pl<\/code>\u00a0\u2014 todo esto ofrece fragmentos de informaci\u00f3n sobre c\u00f3mo-lo-hacemos-ahora. Sin embargo, si usas una p\u00e1gina para buscar un documento, obtienes primero un resultado igualmente malo:<\/p>\n
Informe del grupo de trabajo sobre criptolog\u00eda y teor\u00eda de c\u00f3digos<\/p>\n
http:\/\/www.nsf.gov\/cgi-bin\/getpub?nsf9814<\/pre>\n
\npara la p\u00e1gina de \u00edndice del documento, aunque el documento html mismo se ve mucho mejor:<\/p>\n
http:\/\/www.nsf.gov\/pubs\/1998\/nsf9814\/nsf9814.htm<\/pre>\n
\nAqu\u00ed el encabezado pubs\/1998 dar\u00e1 a cualquier servicio de archivo futuro una buena clave para entender que sigue vigente el antiguo esquema de clasificaci\u00f3n de documentos de 1998. Aunque en 2098 los n\u00fameros de documentos pueden verse diferentes, puedo imaginar que este URI a\u00fan ser\u00e1 v\u00e1lido, y no obstaculizar\u00e1 a la NSF o cualquier otra organizaci\u00f3n que mantenga el archivo.<\/p>\n
No pens\u00e9 que las URL debieran ser permanentes \u2014 ya exist\u00edan las URN.<\/h4>\n
\nProbablemente, 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\u00e1s permanente, pueden tratar de forma negligente los enlaces rotos, ya que \u00ablas URN lo solucionar\u00e1n todo\u00bb. Si eres una de esas personas, perm\u00edteme decepcionarte.<\/p>\n
La mayor\u00eda 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\u00f3n podr\u00e1 crear URN de larga vida, demu\u00e9stralo 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\u00f3n. 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\u00f3n real de archivos.<\/p>\n
Si has llegado hasta aqu\u00ed, entonces si no tienes tiempo, dinero y conexiones para desarrollar alg\u00fan software, puedes hacer la siguiente declaraci\u00f3n justificante:<\/p>\n
Quer\u00edamos, pero simplemente no tenemos las herramientas necesarias.<\/h4>\n
\nEsto merece compasi\u00f3n. Estoy completamente de acuerdo. Lo que necesitas hacer es hacer que el servidor web procese instant\u00e1neamente el URI permanente y devuelva el archivo, donde sea que est\u00e9 almacenado en este momento en tu loca sistema de archivos actual. Quieres almacenar todos los URI en un archivo como verificaci\u00f3n y mantener constantemente la base de datos actualizada. Quieres mantener las relaciones entre diferentes versiones y traducciones del mismo documento, as\u00ed como mantener un registro independiente de suma de verificaci\u00f3n para protegerte contra la corrupci\u00f3n 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\u00e1 que establezcas un URI.<\/p>\n
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.<\/p>\n
Todo es muy malo. Pero lo solucionaremos. En W3C utilizamos la funcionalidad Jigedit (el servidor Jigsaw para edici\u00f3n), que rastrea versiones, y estamos experimentando con scripts para crear documentos. Si est\u00e1s desarrollando herramientas, servidores y clientes, ten en cuenta este problema.<\/p>\n
Esta justificaci\u00f3n tambi\u00e9n se aplica a muchas p\u00e1ginas de W3C, incluida esta: as\u00ed que haz lo que digo y no lo que hago.<\/p>\n
\u00bfPor qu\u00e9 deber\u00eda importarme esto?<\/h1>\n
\nCuando cambias el URI en tu servidor, nunca puedes decir con certeza qui\u00e9n tendr\u00e1 enlaces al antiguo URI. Pueden ser enlaces de p\u00e1ginas web habituales. Favoritos a tu p\u00e1gina. El URI podr\u00eda haber sido garabateado en los m\u00e1rgenes de una carta a un amigo.<\/p>\n
Cuando alguien hace clic en un enlace y est\u00e1 roto, generalmente pierde la confianza en el propietario del servidor. Tambi\u00e9n se siente decepcionado, tanto emocional como realmente, al no poder alcanzar su objetivo.<\/p>\n
Muchas personas se quejan constantemente de enlaces rotos, y espero que el da\u00f1o sea evidente. Espero que tambi\u00e9n sea evidente el da\u00f1o reputacional al mantenedor del servidor donde ha desaparecido el documento.<\/p>\n
\u00bfEntonces, qu\u00e9 debo hacer? Dise\u00f1ar el URI<\/h1>\n
\nEs deber del webmaster crear URIs que se puedan utilizar dentro de 2 a\u00f1os, 20 a\u00f1os o 200 a\u00f1os. Para ello se necesita reflexi\u00f3n, organizaci\u00f3n y determinaci\u00f3n.<\/p>\n
Los URIs cambian si se modifica alguna informaci\u00f3n en ellos. Es muy importante c\u00f3mo los dise\u00f1as. (\u00bfQu\u00e9, dise\u00f1ar el URI? \u00bfNecesito dise\u00f1ar el URI? S\u00ed, deber\u00edas pensar en esto). Dise\u00f1ar significa principalmente que no debe haber informaci\u00f3n alguna en el URI.<\/p>\n
La fecha de creaci\u00f3n del documento \u2014 la fecha en que se emite el URI \u2014 es algo que nunca cambiar\u00e1. Es muy \u00fatil 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\u00e1 relevante en el futuro, es un buen comienzo.<\/p>\n
La \u00fanica excepci\u00f3n es una p\u00e1gina que intencionadamente es la \u00ab\u00faltima\u00bb versi\u00f3n, por ejemplo, para toda la organizaci\u00f3n o una gran parte de ella.<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/latest\/<\/pre>\n
\nEsta es la \u00faltima columna de Money Daily en la revista Money. La raz\u00f3n principal por la que esta URI no necesita una fecha es que no hay razones para mantener una URI que sobrevivir\u00e1 a la revista. El concepto de Money Daily desaparecer\u00e1 cuando Money desaparezca. Si deseas referenciar contenido, deber\u00edas hacerlo por separado en los archivos:<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/1998\/981212.moneyonline.html<\/pre>\n
\n(Se ve bien. Supone que \"money\" significar\u00e1 lo mismo durante toda la existencia de pathfinder.com. Hay duplicaci\u00f3n de \"98\" y un innecesario \".html\", pero en el resto parece un URI s\u00f3lido.<\/p>\n
Qu\u00e9 dejar de lado<\/h4>\n
\n\u00a1Todo! Aparte de la fecha de creaci\u00f3n, al poner cualquier informaci\u00f3n en el URI, de alguna manera te est\u00e1s buscando problemas.<\/p>\n