Autor: Sir Tim Berners-Lee, inventor de URIs, URLs, HTTP, HTML e da World Wide Web, e atual chefe do W3C. Artigo escrito em 1998

Qual URI é considerado "legal"?
Um que não muda.
Como os URIs são alterados?
URIs não mudam: as pessoas os mudam.

Em teoria, não há razão para as pessoas alterarem os URIs (ou deixarem de documentar os documentos comprovativos), mas na prática existem milhões deles.

Em teoria, o proprietário nominal de um namespace de domínio, na verdade, possui o namespace de domínio e, portanto, todos os URIs dentro dele. Além da insolvência, nada impede que o proprietário de um nome de domínio mantenha o nome. E, em teoria, o espaço URI sob o seu nome de domínio está inteiramente sob seu controle, então você pode torná-lo tão estável quanto desejar. Praticamente a única boa razão para um documento desaparecer da Internet é que a empresa proprietária do nome de domínio faliu ou não pode mais manter o servidor funcionando. Então por que existem tantos elos perdidos no mundo? Parte disso é simplesmente falta de premeditação. Aqui estão alguns motivos pelos quais você pode ouvir:

Acabamos de reorganizar o site para torná-lo melhor.

Você realmente acha que os antigos URIs não funcionam mais? Se sim, então você os escolheu muito mal. Considere manter os novos para a próxima reformulação.

Temos tantas coisas que não conseguimos controlar o que está desatualizado, o que é confidencial e o que ainda é relevante, então achamos melhor simplesmente desligar tudo.

Eu só posso simpatizar. O W3C passou por um período em que tivemos que examinar cuidadosamente os materiais de arquivo em busca de confidencialidade antes de torná-los públicos. A decisão deve ser pensada com antecedência - certifique-se de registrar em cada documento um público aceitável, uma data de criação e, idealmente, uma data de validade. Salve esses metadados.

Bem, descobrimos que precisamos mover arquivos...

Esta é uma das desculpas mais patéticas. Muitas pessoas não sabem que os servidores web permitem controlar o relacionamento entre o URI de um objeto e sua localização real no sistema de arquivos. Pense no espaço URI como um espaço abstrato, perfeitamente organizado. Em seguida, faça um mapeamento para qualquer realidade que você realmente use para realizá-la. Em seguida, relate isso ao servidor web. Você pode até escrever seu próprio snippet de servidor para acertar.

John não mantém mais esse arquivo, Jane agora o faz.

O nome de John estava no URI? Não, o arquivo estava apenas no diretório dele? Bem, ok.

Anteriormente usávamos um script CGI para isso, mas agora usamos um programa binário.

Existe uma ideia maluca de que as páginas criadas por scripts devem estar localizadas na área "cgibin" ou "cgi". Isso expõe a mecânica de como você executa seu servidor web. Você altera o mecanismo (mesmo ao salvar o conteúdo) e, opa - todos os seus URIs mudam.

Veja a National Science Foundation (NSF), por exemplo:

Documentos on-line 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á a mesma daqui a alguns anos. cgi-bin, oldbrowse и pl - tudo isso fornece informações sobre como fazemos agora. Se você usar a página para pesquisar um documento, o primeiro resultado obtido será igualmente ruim:

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 documento HTML em si 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 pista de que o antigo esquema de classificação de documentos de 1998 está em vigor. Embora os números dos documentos possam parecer diferentes em 2098, imagino que este URI ainda seria válido e não interferiria com a NSF ou qualquer outra organização que mantivesse o arquivo.

Não achei que os URLs precisassem ser persistentes - havia URNs.

Este é provavelmente um dos piores efeitos colaterais do debate sobre URN. Algumas pessoas pensam que, devido à pesquisa sobre um namespace mais permanente, elas podem ser descuidadas com links pendentes porque "URNs consertarão tudo isso". Se você é uma dessas pessoas, deixe-me decepcioná-lo.

A maioria dos esquemas URN que vi parecem um identificador de autoridade seguido por uma data e uma string que você seleciona ou apenas uma string que você seleciona. Isso é muito semelhante a um URI HTTP. Em outras palavras, se você acha que sua organização será capaz de criar URNs de longa duração, prove isso agora usando-os para seus URIs HTTP. Não há nada no próprio HTTP que torne seu URI instável. Somente sua organização. Crie um banco de dados que mapeie o URN do documento para o nome do arquivo atual e deixe o servidor web usá-lo para realmente recuperar os arquivos.

Se você chegou a este ponto, se não tem tempo, dinheiro e conexões para desenvolver algum software, então você pode apresentar a seguinte desculpa:

Queríamos, mas simplesmente não temos as ferramentas certas.

Mas você pode simpatizar com isso. Eu concordo completamente. O que você precisa fazer é forçar o servidor web a analisar instantaneamente o URI persistente e retornar o arquivo onde quer que esteja armazenado em seu sistema de arquivos maluco atual. Você deseja armazenar todos os URIs em um arquivo como verificação e manter o banco de dados sempre atualizado. Você deseja preservar o relacionamento entre diferentes versões e traduções do mesmo documento e também manter um registro de soma de verificação independente para garantir que o arquivo não seja corrompido por um erro acidental. E os servidores web simplesmente não vêm com esses recursos. Quando você deseja criar um novo documento, seu editor solicita que você especifique um URI.

Você precisa ser capaz de alterar a propriedade, o acesso aos documentos, a segurança no nível do arquivo, etc. no espaço URI sem alterar o URI.

É tudo muito ruim. Mas vamos corrigir a situação. No W3C, usamos a funcionalidade Jigedit (servidor de edição Jigsaw) que rastreia versões e experimentamos scripts de criação de documentos. Se você desenvolve ferramentas, servidores e clientes, preste atenção nesse assunto!

Esta desculpa também se aplica a muitas páginas do W3C, incluindo esta: faça o que eu digo, não o que eu faço.

Por que eu deveria me importar?

Ao alterar o URI em seu servidor, você nunca poderá saber completamente quem terá links para o URI antigo. Podem ser links de páginas da web normais. Marque sua página. O URI pode ter sido rabiscado nas margens de uma carta para um amigo.

Quando alguém segue um link e ele é quebrado, geralmente perde a confiança no proprietário do servidor. Ele também fica frustrado, tanto emocional quanto fisicamente, por não conseguir atingir seu objetivo.

Muitas pessoas reclamam o tempo todo de links quebrados, e espero que o dano seja óbvio. Espero que o dano à reputação do mantenedor do servidor onde o documento desapareceu também seja óbvio.

Então, o que eu deveria fazer? Projeto de URI

É responsabilidade do webmaster alocar URIs que possam ser utilizadas em 2 anos, em 20 anos, em 200 anos. Isso requer consideração, organização e determinação.

Os URIs mudam se alguma informação neles for alterada. Como você os projeta é muito importante. (O que, design de URI? Preciso projetar o URI? Sim, você deveria pensar sobre isso). Design basicamente significa omitir qualquer informação no URI.

A data em que o documento foi criado – a data em que o URI foi emitido – é algo que nunca mudará. É muito útil para separar consultas que utilizam o novo sistema daquelas que utilizam o sistema antigo. Este é um bom lugar para começar com um URI. Se um documento estiver desatualizado, mesmo que seja relevante no futuro, este é 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 grande parte dela.

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

Esta é a última coluna Money Daily da revista Money. A principal razão pela qual não há necessidade de uma data neste URI é que não há razão para armazenar o URI que sobreviverá ao log. O conceito de Money Daily desaparecerá quando o Money desaparecer. Se desejar criar um link para o conteúdo, você deve criar um link para ele separadamente nos arquivos:

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

(Parece bom. Supõe que "dinheiro" significará a mesma coisa ao longo da vida do pathfinder.com. Há um "98" duplicado e um ".html" desnecessário, mas por outro lado parece um URI forte.

O que deixar de lado

Todos! Além da data de criação, colocar qualquer informação no URI é causar problemas de uma forma ou de outra.

• Nome do autor. A autoria pode mudar à medida que novas versões forem disponibilizadas. As pessoas deixam as organizações e passam coisas para outras pessoas.
• Assunto. É muito difícil. Sempre parece bom no início, mas muda surpreendentemente rápido. Falarei mais sobre isso abaixo.
• Estado. Diretórios como "antigo", "rascunho" e assim por diante, sem falar em "mais recente" e "legal", aparecem em todos os sistemas de arquivos. Os documentos mudam de status - caso contrário, não faria sentido criar rascunhos. A versão mais recente de um documento precisa de um identificador persistente, independentemente do 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 parece bom, mas é claro que os documentos começam como ideias da equipe, são discutidos com os membros e depois se tornam de conhecimento público. Seria realmente uma pena se cada vez que um documento fosse aberto para discussão mais ampla, todos os links antigos para ele fossem quebrados! Agora passamos para um código de data simples.
• Extensão de arquivo. Uma ocorrência muito comum. "cgi", até mesmo ".html" mudará no futuro. Você pode não usar HTML para esta página há 20 anos, mas os links atuais para ela ainda devem funcionar. Links canônicos no site W3C não usam a extensão (como isso é feito).
• Mecanismos de software. No URI, procure por “cgi”, “exec” e outros termos que gritam “veja qual software estamos usando”. Alguém quer passar a vida inteira escrevendo scripts Perl CGI? Não? Em seguida, remova a extensão .pl. Leia o manual do servidor sobre como fazer isso.
• Nome do disco. Vamos! Mas eu já vi isso.

Portanto, o melhor exemplo do nosso site é simplesmente

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

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

Tópicos e classificação por tópico

Entrarei em mais detalhes sobre esse perigo, pois é uma das coisas mais difíceis de evitar. Normalmente, os tópicos acabam em URIs quando você categoriza seus documentos pelo trabalho que realizam. Mas esta repartição mudará com o tempo. Os nomes das áreas mudarão. No W3C queríamos mudar MarkUP para Markup e depois para HTML para refletir o conteúdo real da seção. Além disso, geralmente há um namespace simples. Daqui a 100 anos, você tem certeza de que não vai querer reutilizar nada? Na nossa curta vida já quisemos reaproveitar “Histórico” e “Folhas de estilo” por exemplo.

É uma maneira tentadora de organizar um site – e uma maneira verdadeiramente tentadora de organizar qualquer coisa, inclusive toda a Web. Esta é uma excelente solução a médio prazo, mas apresenta sérias deficiências a longo prazo.

Parte da razão reside na filosofia do significado. Cada termo em uma linguagem é um alvo potencial para agrupamento, e cada pessoa pode ter uma ideia diferente do que isso significa. Como os relacionamentos entre entidades são mais parecidos 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 as minhas (frequentemente repetidas) observações gerais sobre os perigos da classificação hierárquica como solução geral.

Na verdade, quando você usa um nome de tópico em um URI, você está se comprometendo com algum tipo de classificação. Talvez no futuro você prefira uma opção diferente. O URI estará então suscetível a violação.

A razão para usar uma área de assunto como parte de um URI é que a responsabilidade pelas subseções do espaço do URI geralmente é delegada, e então você precisa do nome do órgão organizacional - departamento, grupo ou qualquer outro - que é responsável por esse subespaço. Este é um URI vinculado a uma estrutura organizacional. Geralmente só é seguro se o URI mais distante (à esquerda) estiver protegido por uma data: 1998/pics pode significar para o seu servidor "o que queríamos dizer em 1998 com fotos" em vez de "o que em 1998 fizemos com o que agora chamamos de fotos".

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ê possui servidores separados para coisas diferentes, lembre-se de que será impossível alterar essa divisão sem destruir muitos, muitos links. Alguns erros clássicos do tipo "veja o software que usamos hoje" são nomes de domínio "cgi.pathfinder.com", "secure", "lists.w3.org". Eles são projetados para facilitar a administração do servidor. Independentemente de um domínio representar uma divisão na sua empresa, um status de documento, um nível de acesso ou um nível de segurança, tenha muito, muito cuidado antes de usar mais de um nome de domínio para vários tipos de documentos. Lembre-se de que você pode ocultar vários servidores web dentro de um único servidor web visível usando redirecionamento e proxy.

Ah, e pense também no seu nome de domínio. Você não quer ser chamado de soap.com depois de mudar de linha de produtos e parar de fabricar sabonete (desculpe quem é o dono do soap.com no momento).

Conclusão

Preservar um URI por 2, 20, 200 ou mesmo 2000 anos obviamente não é tão fácil quanto parece. No entanto, em toda a Internet, os webmasters estão tomando decisões que tornam essa tarefa realmente difícil para eles no futuro. Muitas vezes isso acontece porque eles utilizam ferramentas cuja função é apresentar o melhor site apenas no momento – e ninguém avaliou o que acontecerá com os links quando tudo mudar. No entanto, a questão aqui é que muitas coisas podem mudar e seus URIs podem e devem permanecer os mesmos. Isso só é possível quando você pensa em como você os cria.

Veja também:

• O discurso de Jakob Nielsen sobre o mesmo assunto

Adições

Como remover extensões de arquivo...

...de um URI no servidor web baseado em arquivo atual?

Se você usa Apache, por exemplo, pode configurá-lo para negociar conteúdo. Salve a extensão do arquivo (por exemplo, .png) em um arquivo (por exemplo, meucachorro.png), mas você pode vincular a um recurso da web sem ele. O Apache então verifica o diretório em busca de todos os arquivos com esse nome e qualquer extensão, e pode escolher o melhor do conjunto (por exemplo, GIF e PNG). E não há necessidade de colocar diferentes tipos de arquivos em diretórios diferentes; na verdade, a correspondência de conteúdo não funcionará se você fizer isso.

• Configure seu servidor para negociar conteúdo
• Sempre vincule a URIs sem extensão

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

(Na verdade, mydog, mydog.png и mydog.gif — recursos web válidos, mydog é um recurso de tipo de conteúdo universal e mydog.png и mydog.gif — recursos de um tipo de conteúdo específico).

É claro que, se você estiver escrevendo seu próprio servidor web, é uma boa ideia usar um banco de dados para vincular identificadores persistentes à sua forma atual, mas tome cuidado com o crescimento ilimitado do banco de dados.

O Conselho da Vergonha - 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 espere que as informações apareçam na parte inferior da tela da TV! Eu criei um link para ele na minha página inicial. A primeira grande tempestade de neve de 2000 chega e eu verifico a página. Está escrito lá:,

- A partir de.
Nada está fechado no momento. Por favor, retorne em caso de avisos meteorológicos.

Não pode ser uma tempestade tão forte. É engraçado que a data esteja faltando. Mas se você for para a página principal 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 para obter a lista - mas não precisaram alterar o URI.

Board of Shame - História 2: Microsoft Netmeeting

Com a crescente dependência da Internet, surgiu uma ideia inteligente de que links para o site do fabricante pudessem ser incorporados em aplicativos. Isso tem sido muito usado e abusado, mas você não pode alterar o URL. Outro dia tentei um link do cliente Microsoft Netmeeting 2/something no menu Ajuda/Microsoft na Web/Coisas gratuitas e recebi um erro 404 - nenhuma resposta do servidor foi encontrada. Talvez já esteja consertado...

© 1998 Tim BL

Nota histórica: No final do século 20, quando isto foi escrito, “cool” era um epíteto de aprovação, especialmente entre os jovens, indicando moda, qualidade ou adequação. Com pressa, o caminho do URI era frequentemente escolhido por "frieza" em vez de utilidade ou durabilidade. Este post é uma tentativa de redirecionar a energia por trás da busca pelo cool.

Fonte: habr.com