Autor — Sir Tim Berners-Lee, inventor do URI, URL, HTTP, HTML e da World Wide Web, atual presidente do W3C. O artigo foi escrito em 1998.

Qual URI pode ser considerado "legal"?
Aquele que não muda.
Como os URIs mudam?
Os URIs não mudam: são as pessoas que os mudam.

Ideiamente, as pessoas não têm motivos para mudar URIs (ou parar de manter documentos), mas na prática, são milhões.

Teoricamente, o proprietário nominal do espaço de nomes de domínio realmente possui o espaço de nomes de domínio e, portanto, todos os URIs nele. Exceto em caso de insolvência, nada impede que o proprietário do domínio mantenha esse nome. E, teoricamente, o espaço URI sob seu nome de domínio está sob seu controle total, permitindo torná-lo tão estável quanto desejar. Em grande parte, a única razão válida para um documento desaparecer da internet é que a empresa que possuía o nome de domínio saiu do negócio ou não pode mais manter o servidor ativo. Então, por que há tantos links quebrados no mundo? Em parte, é apenas uma questão de falta de previsão. Aqui estão algumas razões que você pode ouvir:

Nós simplesmente reorganizamos o site para torná-lo melhor.

Você realmente acha que os antigos URIs não podem funcionar mais? Se sim, você os escolheu muito mal. Pense em garantir que os novos permaneçam após a próxima reformulação.

Temos tanto material que não conseguimos acompanhar o que está desatualizado, o que é confidencial e o que ainda está em dia, então achamos que seria melhor simplesmente desligar tudo isso.

Só posso lamentar. O W3C passou por um período em que precisávamos revisar cuidadosamente os materiais arquivados quanto à privacidade antes de torná-los públicos. A decisão deve ser bem pensada de antemão — certifique-se de registrar para cada documento um público aceitável, a data de criação e, idealmente, o prazo de validade. Mantenha esses metadados.

Bem, descobrimos que precisamos mover os arquivos...

Esta é uma das justificativas mais patéticas. Muitos não sabem que servidores web permitem que você gerencie a conexão entre o URI do objeto e a sua localização real no sistema de arquivos. Imagine o espaço URI como um espaço abstrato, perfeitamente organizado. Então, faça um mapeamento para qualquer realidade que você realmente esteja usando para implementá-lo. Em seguida, informe isso ao servidor web. Você pode até escrever um trecho do seu servidor para fazer tudo certo.

John não dá mais suporte a este arquivo, agora é Jane quem faz isso.

O nome de John estava no URI? Não, o arquivo apenas estava em seu diretório? Bom, entendi.

Antes, usávamos um script CGI para isso, agora estamos usando um programa binário.

Há uma ideia maluca de que as páginas criadas por scripts devem estar localizadas na área "cgibin" ou "cgi". Isso revela o mecanismo de como você roda seu servidor web. Mude o mecanismo (mesmo mantendo o conteúdo) e, ups — todos os seus URIs mudam.

Vamos pegar, por exemplo, a Fundação Nacional de Ciência (NSF):

Documentos online da NSF

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

A primeira página para começar a visualizar documentos claramente não permanecerá assim em alguns anos. cgi-bin, oldbrowse e pl — tudo isso revela fragmentos de informação sobre como fazemos isso agora. Se você estiver usando uma página para encontrar um documento, então obtém o mesmo resultado ruim primeiro:

Relatório do grupo de trabalho sobre criptologia e teoria da codificação

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

para a página de índice do documento, embora o próprio documento html pareça muito melhor:

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

Aqui, o cabeçalho pubs/1998 dará a qualquer serviço de arquivo futuro uma boa chave para compreender que a antiga classificação de documentos de 1998 está em vigor. Embora em 2098 os números dos documentos possam parecer diferentes, posso imaginar que este URI ainda será válido, e isso não impedirá a NSF ou qualquer outra organização que venha a manter o arquivo.

Não pensei que os URLs deveriam ser permanentes — já havia URN.

Provavelmente, esse é um dos piores efeitos colaterais da discussão sobre URN. Alguns pensam que por causa das pesquisas sobre um espaço de nomes mais permanente, podem ser descuidados com links quebrados, pois "URN vai consertar tudo isso". Se você é uma dessas pessoas, deixe-me te decepcionar.

A maioria dos esquemas URN que vi parecem como um identificador de autoridade, seguido por uma data e uma string escolhida por você, ou simplesmente uma string escolhida por você. Isso é muito semelhante a um URI HTTP. Em outras palavras, se você acredita que sua organização será capaz de criar URNs duradouros, prove isso agora, usando-os para seus URIs HTTP. Não há nada no HTTP que torne seu URI instável. Apenas sua organização. Crie um banco de dados que mapeie a URN do documento com o nome do arquivo atual e permita que o servidor web o utilize para a extração real dos arquivos.

Se você chegou até aqui, se não tem tempo, dinheiro e conexões para desenvolver algum software, então pode alegar a seguinte justificativa:

Queríamos, mas simplesmente não temos as ferramentas necessárias.

Isso é compreensível. Concordo plenamente. O que você precisa fazer é fazer com que o servidor web processe imediatamente o URI permanente e retorne o arquivo, onde quer que ele esteja armazenado naquele momento em seu sistema de arquivos maluco. Você deve armazenar todos os URIs em um arquivo como verificação e manter constantemente o banco de dados em conformidade com a atualidade. Você quer manter a relação entre diferentes versões e traduções de um mesmo documento, bem como manter um registro independente da soma de verificação para garantir a proteção contra a corrupção do arquivo devido a um erro aleatório. E servidores web simplesmente não vêm prontos com essas funcionalidades. Quando você deseja criar um novo documento, seu editor pede que você defina o URI.

Você precisa ter a capacidade de alterar a propriedade, o acesso ao documento, o nível de segurança do arquivo e outros aspectos no espaço URI sem alterar o URI.

Está muito ruim. Mas vamos corrigir isso. No W3C, usamos a funcionalidade Jigedit (servidor Jigsaw para edição), que rastreia versões, e estamos experimentando scripts para a criação de documentos. Se você está desenvolvendo ferramentas, servidores e clientes, preste atenção a esse problema!

Essa justificativa se aplica também a muitas páginas do W3C, inclusive esta: então faça o que eu digo, não o que eu faço.

Por que isso deveria me preocupar?

Quando você altera o URI em seu servidor, nunca pode afirmar com certeza quem terá links para o antigo URI. Isso pode ser links de páginas da web comuns. Favoritos da sua página. O URI pode ter sido rabiscado nas margens de uma carta para um amigo.

Quando alguém clica em um link e ele está quebrado, geralmente perde a confiança no proprietário do servidor. Também fica desapontado — tanto emocionalmente quanto de forma prática, por não conseguir atingir seu objetivo.

Muitas pessoas reclamam constantemente sobre links quebrados, e eu espero que o dano seja evidente. Espero que também seja claro o dano reputacional para o mantenedor do servidor onde o documento desapareceu.

Então, o que eu devo fazer? Projetar o URI

É dever do webmaster destacar URIs que poderão ser utilizados em 2 anos, 20 anos, 200 anos. Para isso, é necessária reflexão, organização e determinação.

Os URIs mudam se houver alguma informação alterada. É muito importante como você os projeta. (O que, projetar o URI? Eu preciso projetar URIs? Sim, você deve pensar sobre isso). Projetar significa, em essência, que nenhuma informação deve ser inserida no URI.

A data de criação do documento — a data de emissão do URI — é algo que nunca mudará. É muito útil para diferenciar as solicitações que usam um novo sistema daquelas que usam um sistema antigo. É um bom ponto de partida para o URI. Se um documento tem alguma data impressa, mesmo que o documento se mantenha válido no futuro, isso é um bom começo.

A única exceção é uma página que é intencionalmente a "versão mais recente", por exemplo, para toda a organização ou uma grande parte dela.

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

Esta é a última coluna do Money Daily na revista Money. A principal razão pela qual essa data não é necessária neste URI é que não há razões para preservar um URI que sobreviva à revista. O conceito de Money Daily desaparecerá quando o Money desaparecer. Se você quiser referenciar conteúdo, deve referenciá-lo separadamente nos arquivos:

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

(Parece bom. Supõe que "money" significará a mesma coisa durante toda a existência do pathfinder.com. Há duplicação de "98" e um desnecessário ".html", mas no geral parece um URI forte.

O que deixar de lado

Tudo! Exceto pela data de criação, ao adicionar qualquer informação ao URI, você de alguma forma está se convidando para problemas.

Nome do autor. A autoria pode mudar com o lançamento de novas versões. As pessoas saem das organizações e transmitem as coisas para outros.
Item. Isso é muito complicado. Sempre parece bom no início, mas muda surpreendentemente rápido. Vou explicar isso com mais detalhes abaixo.
Status. Catálogos como "antigo", "rascunho" e assim por diante, sem mencionar "último" e "bacana", aparecem em todos os sistemas de arquivos. Documentos mudam de status — caso contrário, não faz sentido criar rascunhos. A versão mais recente de um documento precisa de um identificador constante, independentemente de seu status. Mantenha o status fora do nome.
Acesso. No W3C, dividimos o site em seções para funcionários, membros e público. Isso soa bem, mas, claro, os documentos começam como ideias da equipe de funcionários, são discutidos com os membros e, em seguida, tornam-se de domínio público. É realmente frustrante se, sempre que um documento é aberto para discussão mais ampla, todos os antigos links para ele se quebram! Agora passamos para um simples código de data.
Extensão do arquivo. Um fenômeno muito comum. "cgi", até ".html" mudará no futuro. Talvez em 20 anos você não use HTML para esta página, mas os links de hoje ainda devem funcionar. Links canônicos no site do W3C não usam extensão (como isso é feito).
Mecanismos de software. No URI, procure por "cgi", "exec" e outros termos que gritam 'veja, que software estamos usando'. Alguém quer dedicar toda a vida a scripts Perl CGI? Não? Então remova a extensão .pl. Consulte o guia do servidor sobre como fazer isso.
Nome do disco. Ah, vá! Mas eu já vi isso.

Então o melhor exemplo do nosso site é simplesmente

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

… o relatório da ata da reunião dos presidentes do W3C.

Temas e classificação por temas

Vou falar mais sobre esse perigo, pois é uma das coisas mais difíceis de evitar. Geralmente, os tópicos aparecem na URI quando você classifica seus documentos de acordo com o trabalho realizado. Mas essa divisão mudará ao longo do tempo. Os nomes das áreas mudarão. Na W3C, quisemos mudar MarkUP para Markup, e depois para HTML, para refletir o conteúdo real da seção. Além disso, muitas vezes há um espaço de nomes plano aqui. Daqui a 100 anos, você certamente não vai querer reutilizar nada? Em nossa breve vida, já quisemos reutilizar "História" e "Folhas de estilo", por exemplo.

É uma maneira atraente de organizar um site — e realmente uma maneira atraente de organizar qualquer coisa, incluindo toda a Rede. É uma ótima solução a médio prazo, mas tem sérias desvantagens a longo prazo.

Parte das razões reside na filosofia do significado. Cada termo em uma linguagem é um potencial objeto de clusterização, e cada pessoa pode ter uma visão diferente do que isso significa. Como as relações entre os sujeitos são mais parecidas com uma teia do que com uma árvore, mesmo aqueles que concordam com a teia podem escolher uma representação diferente da árvore. Estas são minhas (frequentemente repetidas) observações gerais sobre os perigos da classificação hierárquica como uma solução geral.

De fato, ao usar um nome de tópico na URI, você se vincula a uma certa classificação. Pode ser que no futuro você prefira outra opção. Nesse caso, a URI estará sujeita a violação.

A razão para usar uma área temática como parte da URI é que a responsabilidade por subdivisões do espaço URI geralmente é delegada, e então você precisa de um nome de órgão organizacional — uma unidade, grupo ou algo que seja responsável por esse subespaço. Isso vincula a URI à estrutura organizacional. Normalmente, é seguro apenas quando, mais adiante (à esquerda), a URI é protegida por uma data: 1998/pics pode significar para o seu servidor "o que queríamos dizer em 1998 com pics", e não "o que fizemos em 1998 com o que agora chamamos de pics".

Não se esqueça do nome de domínio

Lembre-se de que isso se aplica não apenas ao caminho no URI, mas também ao nome do servidor. Se você tiver servidores separados para diferentes funções, tenha em mente que essa divisão será impossível de alterar sem destruir muitos links. Alguns erros clássicos do tipo "veja qual software estamos usando hoje" — nomes de domínio "cgi.pathfinder.com", "secure", "lists.w3.org". Eles foram criados para facilitar a administração dos servidores. Independentemente de o domínio representar alguma subdivisão em sua empresa, o status do documento, o nível de acesso ou o nível de segurança, tenha muito, muito cuidado antes de usar mais de um nome de domínio para diferentes tipos de documentos. Lembre-se de que você pode ocultar muitos servidores web dentro de um único servidor web visível, usando redirecionamento e proxy.

Sim, e pense também sobre o seu nome de domínio. Você não quer ser referenciado como soap.com depois que mudar sua linha de produtos e parar de fabricar sabonete (peço desculpas ao proprietário do soap.com neste momento).

Conclusão

Manter um URI por 2, 20, 200 ou até 2000 anos, claramente, não é tão simples quanto parece. Contudo, em toda a internet, webmasters tomam decisões que realmente dificultam essa tarefa no futuro. Frequentemente, isso acontece porque eles usam ferramentas cujo objetivo é apresentar o melhor site apenas no momento atual — e ninguém avaliou o que acontecerá com os links quando tudo mudar. No entanto, o ponto aqui é que muita coisa, muita coisa pode mudar, e seus URIs podem e devem permanecer os mesmos. Isso só é possível quando você pensa sobre como os cria.

Veja também:

Discurso de Jakob Nielsen sobre o mesmo tema

Complementos

Como remover extensões de arquivos…

…de URIs no servidor web atual baseado em arquivos?

Se você estiver usando, por exemplo, Apache, pode configurá-lo para reconciliar o conteúdo. Você mantém a extensão do arquivo (por exemplo, .png) no arquivo (por exemplo, mydog.png), mas você pode referenciar um recurso da web sem ele. Em seguida, o Apache verifica o diretório em busca de todos os arquivos com esse nome e qualquer extensão, e também pode escolher o melhor de um conjunto (por exemplo, GIF e PNG). E não é necessário colocar tipos diferentes de arquivos em diretórios diferentes; na verdade, a negociação de conteúdo não funcionará se você fizer isso.

Configure seu servidor para negociação de conteúdo
Sempre faça links para URIs sem extensão

Links com extensões ainda funcionarão, mas não permitirão que seu servidor escolha o melhor formato disponível atualmente e no futuro.

(Na verdade, meupet, mydog.png e mydog.gif — são recursos da web válidos, meupet — são recursos de tipo de conteúdo universal, e mydog.png e mydog.gif — recursos de tipo de conteúdo específico).

Claro, se você estiver escrevendo seu próprio servidor web, é uma boa ideia usar um banco de dados para vincular identificadores permanentes à sua forma atual, embora você deva ter cuidado com o crescimento ilimitado do banco de dados.

Quadro de avisos — História 1: Canal 7

Durante 1999, acompanhei o fechamento de escolas devido à neve na página http://www.whdh.com/stormforce/closings.shtml. Não dá para esperar que as informações apareçam na parte inferior da tela da TV! Eu coloquei um link para isso na minha página inicial. Chega a primeira grande tempestade de neve de 2000, e eu verifico a página. Diz:

— Até agora.
Neste momento, nada está fechado. Por favor, volte em caso de avisos meteorológicos.

Não pode ser, uma tempestade tão forte. Engraçado, que a data está ausente. Mas se você acessar a página inicial do site, haverá um grande botão 'Escolas fechadas', que leva à página http://www.whdh.com/stormforce/ com uma longa lista de escolas fechadas.

Talvez eles tenham mudado o sistema de obtenção da lista — mas não precisavam mudar a URI.

Quadro de avisos — História 2: Microsoft Netmeeting

Com a crescente dependência da internet, surgiu a ideia inteligente de incorporar links para o site do fabricante nos aplicativos. Isso foi amplamente utilizado e muito abusado, mas — não se pode mudar a URL. Recentemente, experimentei um link do cliente Microsoft Netmeeting 2/something no menu Ajuda/Microsoft na Web/Coisas grátis e recebi um erro 404 — resposta não encontrada do servidor. Talvez já tenham consertado...

Nota histórica: no final do século 20, quando isso foi escrito, "legal" era um epíteto de aprovação, especialmente entre os jovens, indicando estilo, qualidade ou relevância. Na pressa, muitas vezes a escolha do caminho URI era feita pela "legalidade", ao invés de utilidade ou durabilidade. Esta nota é uma tentativa de redirecionar a energia por trás da busca pela legalidade.

Fonte: habr.com