Autor: Sir Tim Berners-Lee, inventor de URI, URL, HTTP, HTML e World Wide Web, e actual xefe do W3C. Artigo escrito en 1998

Que URI se considera "cool"?
Un que non cambia.
Como cambian os URI?
Os URI non cambian: a xente cámbiaos.

En teoría, non hai motivos para que a xente cambie os URI (ou deixen de xustificar os documentos), pero na práctica hai millóns deles.

En teoría, o propietario nominal dun espazo de nomes de dominio realmente é o propietario do espazo de nomes de dominio e, polo tanto, de todos os URI dentro del. Ademais da insolvencia, nada impide que o propietario dun nome de dominio manteña o nome. E, en teoría, o espazo URI baixo o teu nome de dominio está totalmente baixo o teu control, polo que podes facelo tan estable como queiras. Practicamente a única boa razón para que un documento desapareza de Internet é que a empresa propietaria do nome de dominio quedou fóra do negocio ou xa non pode permitirse o luxo de manter o servidor funcionando. Entón, por que hai tantos enlaces perdidos no mundo? Algo disto é simplemente unha falta de previsión. Aquí tes algunhas razóns polas que podes escoitar:

Acabamos de reorganizar o sitio para melloralo.

Realmente pensas que os antigos URI xa non poden funcionar? Se é así, entón escolleches moi mal. Considera manter os novos para o próximo redeseño.

Temos tantas cousas que non podemos facer un seguimento do que está desactualizado, do que é confidencial e do que aínda é relevante, polo que pensamos que era mellor desactivalo todo.

Só podo simpatizar. O W3C pasou por un período no que tivemos que examinar coidadosamente os materiais de arquivo para garantir a confidencialidade antes de facelos públicos. A decisión debe ser pensada con antelación: asegúrese de que con cada documento rexistre o número de lectores aceptable, a data de creación e, idealmente, a data de caducidade. Garda estes metadatos.

Ben, descubrimos que necesitamos mover ficheiros...

Esta é unha das escusas máis patéticas. Moita xente non sabe que os servidores web permiten controlar a relación entre o URI dun obxecto e a súa localización real no sistema de ficheiros. Pense no espazo URI como un espazo abstracto, perfectamente organizado. A continuación, fai un mapeo para calquera realidade que realmente uses para realizala. A continuación, informe ao servidor web. Incluso podes escribir o teu propio fragmento de servidor para facelo ben.

John xa non mantén este ficheiro, agora si Jane.

O nome de John estaba no URI? Non, o ficheiro estaba só no seu directorio? Ben, vale.

Anteriormente usabamos un script CGI para iso, pero agora usamos un programa binario.

Hai unha idea tola de que as páxinas creadas por scripts deberían estar situadas na área "cgibin" ou "cgi". Isto expón a mecánica de como executas o teu servidor web. Cambias o mecanismo (mesmo mentres gardas contido) e vaia, todos os teus URIs cambian.

Tome a National Science Foundation (NSF) por exemplo:

Documentos en liña da NSF

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

A primeira páxina para comezar a ver documentos claramente non seguirá sendo a mesma dentro duns anos. cgi-bin, oldbrowse и pl - todo isto dá información sobre como-facemos-agora. Se utilizas a páxina para buscar un documento, o primeiro resultado que obtén é igualmente malo:

Informe do Grupo de Traballo de Criptoloxía e Teoría da Codificación

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

para a páxina de índice do documento, aínda que o propio documento html parece moito mellor:

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

Aquí a cabeceira pubs/1998 dará a calquera futuro servizo de arquivo unha boa pista de que o antigo esquema de clasificación de documentos de 1998 está en vigor. Aínda que os números do documento poden parecer diferentes en 2098, imaxinaríame que este URI aínda sería válido e non interferiría con NSF nin con ningunha outra organización que manteña o arquivo.

Non pensei que os URL tivesen que ser persistentes: había URN.

Este é probablemente un dos peores efectos secundarios do debate das URN. Algunhas persoas pensan que, debido á investigación sobre un espazo de nomes máis permanente, poden ser descoidados coas ligazóns colgantes porque "as URN solucionarán todo iso". Se es unha destas persoas, déixame decepcionarte.

A maioría dos esquemas de URN que vin parecen un identificador de autoridade seguido dunha data e dunha cadea que seleccione ou só dunha cadea que seleccione. Isto é moi semellante a un URI HTTP. Noutras palabras, se pensas que a túa organización será capaz de crear URN de longa duración, probalo agora usándoos para os teus URI HTTP. Non hai nada no propio HTTP que faga que o teu URI sexa inestable. Só a túa organización. Cree unha base de datos que asigne o URN do documento ao nome do ficheiro actual e deixe que o servidor web o use para recuperar os ficheiros.

Se chegaches a este punto, se non tes tempo, diñeiro e conexións para desenvolver algún software, podes indicar a seguinte escusa:

Queriamos, pero non temos as ferramentas adecuadas.

Pero podes simpatizar con isto. Estou totalmente de acordo. O que cómpre facer é forzar ao servidor web a analizar instantaneamente o URI persistente e devolver o ficheiro onde queira que estea almacenado no seu tolo sistema de ficheiros actual. Quere almacenar todos os URI nun ficheiro como comprobación e manter a base de datos actualizada en todo momento. Quere preservar a relación entre as diferentes versións e traducións do mesmo documento e tamén manter un rexistro independente de suma de comprobación para garantir que o ficheiro non estea corrompido por un erro accidental. E os servidores web simplemente non saen da caixa con estas funcións. Cando quere crear un novo documento, o seu editor pídelle que especifique un URI.

Debes poder cambiar a propiedade, o acceso ao documento, a seguridade do nivel de arquivo, etc. no espazo URI sen cambiar o URI.

É moi malo. Pero corrixiremos a situación. No W3C, usamos a funcionalidade Jigedit (servidor de edición Jigsaw) que rastrexa versións e experimentamos con scripts de creación de documentos. Se desenvolves ferramentas, servidores e clientes, presta atención a este problema.

Esta escusa tamén se aplica a moitas páxinas do W3C, incluída esta: así que faga o que digo, non como fago eu.

Por que me debería importar?

Cando cambias o URI do teu servidor, nunca poderás dicir completamente quen terá ligazóns ao antigo URI. Estes poden ser ligazóns de páxinas web habituais. Marca a túa páxina como favoritos. O URI podería estar garabateado nas marxes dunha carta a un amigo.

Cando alguén segue unha ligazón e está rota, normalmente perde a confianza no propietario do servidor. Tamén está frustrado, tanto emocional como físicamente, por non conseguir o seu obxectivo.

Moita xente quéixase de ligazóns rotas todo o tempo, e espero que o dano sexa evidente. Espero que o dano á reputación do mantedor do servidor onde desapareceu o documento tamén sexa evidente.

Entón, que debería facer? Deseño de URI

É responsabilidade do webmaster asignar URIs que se poidan utilizar en 2 anos, en 20 anos, en 200 anos. Isto require reflexión, organización e determinación.

Os URI cambian se cambia algunha información neles. Como os deseñas é moi importante. (Que, deseño de URI? Necesito deseñar o URI? Si, deberías pensar niso). Deseño significa basicamente deixar fóra calquera información no URI.

A data na que se creou o documento -a data na que se emitiu o URI- é algo que nunca cambiará. É moi útil para separar consultas que usan o sistema novo das que usan o sistema antigo. Este é un bo lugar para comezar cun URI. Se un documento está datado, aínda que o documento sexa relevante no futuro, este é un bo comezo.

A única excepción é unha páxina que é intencionalmente a "última" versión, por exemplo para toda a organización ou gran parte dela.

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

Esta é a última columna Money Daily da revista Money. A principal razón pola que este URI non necesita unha data é porque non hai razón para almacenar o URI que sobrevivirá ao rexistro. O concepto de Money Daily desaparecerá cando Money desapareza. Se queres ligar ao contido, debes ligar a el por separado nos arquivos:

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

(Parece ben. Asume que o "diñeiro" significará o mesmo durante toda a vida de pathfinder.com. Hai un "98" duplicado e un ".html" innecesario, pero polo demais parece un URI forte.

Que deixar de lado

Todo! Ademais da data de creación, poñer calquera información no URI é pedir problemas dun xeito ou doutro.

Nome do autor. A autoría pode cambiar a medida que estean dispoñibles novas versións. A xente deixa as organizacións e pasa cousas a outras.
Asunto. É moi difícil. Sempre se ve ben ao principio, pero cambia sorprendentemente rapidamente. Vou falar máis sobre isto a continuación.
Estado. En todos os sistemas de ficheiros aparecen directorios como "antigo", "borrador", etc., sen esquecer "último" e "cool". Os documentos cambian de estado; se non, non tería sentido crear borradores. A última versión dun documento necesita un identificador persistente, independentemente do seu estado. Mantén o estado fóra do nome.
Acceso. No W3C, dividimos o sitio en seccións para empregados, membros e público. Isto soa ben, pero, por suposto, os documentos comezan como ideas do equipo do persoal, son discutidos cos membros e despois fanse de coñecemento público. Sería realmente unha mágoa que cada vez que se abre un documento para un debate máis amplo, se rompen todas as ligazóns antigas. Agora pasamos a un código de data sinxelo.
Extensión de ficheiro. Un fenómeno moi común. "cgi", incluso ".html" cambiará no futuro. É posible que non uses HTML para esta páxina en 20 anos, pero as ligazóns de hoxe a ela deberían seguir funcionando. As ligazóns canónicas do sitio W3C non usan a extensión (como se fai).
Mecanismos de software. No URI, busque "cgi", "exec" e outros termos que berran "mira que software estamos a usar". Alguén quere pasar a súa vida enteira escribindo scripts Perl CGI? Non? A continuación, elimine a extensión .pl. Lea o manual do servidor sobre como facelo.
Nome do disco. Veña! Pero eu vin isto.

Polo tanto, o mellor exemplo do noso sitio é simplemente

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

... informe sobre as actas da reunión de presidentes do W3C.

Temas e clasificación por temas

Vou entrar máis en detalle sobre este perigo, xa que é unha desas cousas que é máis difícil de evitar. Normalmente, os temas acaban en URI cando clasificas os teus documentos polo traballo que realizan. Pero esta descomposición cambiará co paso do tempo. Os nomes das áreas cambiarán. No W3C queriamos cambiar MarkUP a Marcado e logo a HTML para reflectir o contido real da sección. Ademais, moitas veces hai un espazo de nomes plano. Dentro de 100 anos, estás seguro de que non quererás reutilizar nada? Na nosa curta vida xa quixemos reutilizar "Historia" e "Follas de estilo", por exemplo.

É unha forma tentadora de organizar un sitio web e unha forma verdadeiramente tentadora de organizar calquera cousa, incluída a web enteira. Esta é unha excelente solución a medio prazo, pero ten graves deficiencias a longo prazo.

Parte da razón reside na filosofía do significado. Cada termo nunha lingua é un obxectivo potencial para agrupar, e cada persoa pode ter unha idea diferente do que significa. Dado que as relacións entre entidades se parecen máis a unha web que a unha árbore, mesmo aqueles que estean de acordo coa web poden escoller unha representación diferente da árbore. Estas son as miñas (moitas veces repetidas) observacións xerais sobre os perigos da clasificación xerárquica como solución xeral.

De feito, cando usas un nome de tema nun URI, estás comprometendote con algún tipo de clasificación. Quizais no futuro prefira unha opción diferente. O URI será entón susceptible de violación.

O motivo para usar unha área temática como parte dun URI é que a responsabilidade das subseccións do espazo URI adoita delegarse, e entón necesitas o nome do órgano organizativo -departamento, grupo ou o que sexa- que é responsable dese subespazo. Este é un URI vinculante a unha estrutura organizativa. Normalmente só é seguro se o URI (á esquerda) está protexido por unha data: 1998/pics pode significar para o teu servidor "o que queriamos dicir en 1998 con fotos" en lugar de "o que fixemos en 1998 co que agora chamamos imaxes".

Non esquezas o nome de dominio

Lembre que isto aplícase non só ao camiño no URI, senón tamén ao nome do servidor. Se tes servidores separados para cousas diferentes, lembra que será imposible cambiar esta división sen destruír moitas, moitas ligazóns. Algúns erros clásicos de "mira o software que usamos hoxe" son os nomes de dominio "cgi.pathfinder.com", "secure", "lists.w3.org". Están deseñados para facilitar a administración do servidor. Independentemente de se un dominio representa unha división na súa empresa, un estado de documento, un nivel de acceso ou un nivel de seguridade, teña moito, moito coidado antes de usar máis dun nome de dominio para varios tipos de documentos. Lembre que pode ocultar varios servidores web dentro dun único servidor web visible mediante a redirección e o proxy.

Ah, e tamén pensa no teu nome de dominio. Non queres que che fagan referencia a soap.com despois de cambiar as liñas de produtos e deixar de fabricar xabón (perdón polo propietario de soap.com neste momento).

Conclusión

Conservar un URI durante 2, 20, 200 ou mesmo 2000 anos, obviamente, non é tan sinxelo como parece. Non obstante, en toda Internet, os administradores web están tomando decisións que lles dificultan realmente esta tarefa no futuro. Moitas veces isto débese a que usan ferramentas cuxo traballo é presentar o mellor sitio só no momento, e ninguén avaliou que pasará coas ligazóns cando todo cambie. Non obstante, o punto aquí é que moitas, moitas cousas poden cambiar, e os teus URI poden e deben seguir sendo os mesmos. Isto só é posible cando pensas en como crealos.

Vexa tamén:

A diatriba de Jakob Nielsen sobre o mesmo tema

Adicións

Como eliminar extensións de ficheiros...

...desde un URI do servidor web baseado en ficheiros actual?

Se usas Apache, por exemplo, podes configuralo para negociar contido. Garda a extensión do ficheiro (p. ex. .png) nun ficheiro (p. ex. o meu can.png), pero pode enlazar a un recurso web sen el. A continuación, Apache verifica no directorio todos os ficheiros con ese nome e calquera extensión, e pode escoller o mellor do conxunto (por exemplo, GIF e PNG). E non é necesario poñer diferentes tipos de ficheiros en diferentes directorios, de feito, a coincidencia de contidos non funcionará se o fas.

Configura o teu servidor para negociar contido
Enlazar sempre con URI sen extensión

As ligazóns con extensións seguirán funcionando, pero impedirán que o teu servidor elixa o mellor formato dispoñible actualmente e no futuro.

(De feito, mydog, mydog.png и mydog.gif - recursos web válidos, mydog é un recurso de tipo de contido universal e mydog.png и mydog.gif — recursos dun tipo de contido específico).

Por suposto, se está a escribir o seu propio servidor web, é unha boa idea utilizar unha base de datos para vincular os identificadores persistentes á súa forma actual, aínda que teña coidado co crecemento ilimitado da base de datos.

The Board of Shame - Historia 1: Canal 7

Durante 1999, fixen un seguimento dos peches de escolas debido á neve na páxina http://www.whdh.com/stormforce/closings.shtml. Non esperes a que apareza a información na parte inferior da pantalla do televisor. Enlacei a el desde a miña páxina de inicio. Chega a primeira gran tormenta de neve do ano 2000 e comprobo a páxina. Alí está escrito:,

- A partir de.
Nada está pechado actualmente. Regrese en caso de aviso meteorolóxico.

Non pode ser unha tormenta tan forte. É curioso que falte a data. Pero se vai á páxina principal do sitio, haberá un gran botón "Escolas pechadas", que leva á páxina http://www.whdh.com/stormforce/ cunha longa lista de escolas pechadas.

Quizais cambiaron o sistema para obter a lista, pero non precisaron cambiar o URI.

Board of Shame - Historia 2: Microsoft Netmeeting

Coa crecente dependencia de Internet, xurdiu unha idea intelixente de que as ligazóns ao sitio web do fabricante puidesen incorporarse nas aplicacións. Utilizouse e abusouse moito desta función, pero non podes cambiar o URL. O outro día tentei unha ligazón do cliente Microsoft Netmeeting 2/algo no menú Axuda/Microsoft na web/Cousas gratuítas e recibín un erro 404: non se atopou ningunha resposta do servidor. Quizais xa está arranxado...

Nota histórica: a finais do século XX, cando se escribiu isto, "cool" era un epíteto de aprobación, especialmente entre os mozos, que indicaba moda, calidade ou conveniencia. Con présa, a ruta do URI elixíase a miúdo por "coolidade" en lugar de por utilidade ou durabilidade. Esta publicación é un intento de redirixir a enerxía que hai detrás da busca de cool.

Fonte: www.habr.com

Os URI interesantes non cambian