O que URI é legal?
Aquele que não muda.
Como os URIs mudam?
URIs não mudam: as pessoas os mudam.
Em teoria, não há razão para que as pessoas mudem URIs (ou parem de manter documentos), mas na prática existem milhões.
Em teoria, o proprietário nominal do namespace de domínio realmente possui o namespace de domínio e, portanto, todos os URIs nele. Além da insolvência, nada impede que o proprietário do nome de domínio mantenha esse nome. E, em teoria, o espaço URI em seu nome de domínio está completamente sob seu controle, então você pode torná-lo o mais estável que desejar. Praticamente a única boa razão para um documento desaparecer da Internet é que a empresa que possuía o nome de domínio faliu ou não pode mais manter o servidor funcionando. Então, por que existem tantos elos perdidos no mundo? Em parte, isso é apenas uma falta de previsão. Aqui estão alguns dos motivos pelos quais você pode ouvir:
Acabamos de reorganizar o site para torná-lo melhor.
Você realmente sente que os URIs antigos não podem mais funcionar? Em caso afirmativo, você os escolheu muito mal. Considere manter os novos da próxima reformulação.
Temos tanto material que não podemos controlar o que está desatualizado, o que é confidencial e o que ainda é relevante, por isso pensamos que seria melhor apenas desligá-lo.
Eu só posso simpatizar. O W3C passou por um período em que tivemos que examinar cuidadosamente o material de arquivo para fins de confidencialidade antes de torná-lo público. A decisão deve ser pensada com antecedência - certifique-se de registrar com cada documento um público aceitável, data de criação e, idealmente, data de validade. Salve esses metadados.
Bem, descobrimos que precisávamos mover os arquivos ...
Esta é uma das desculpas mais patéticas. Muitas pessoas não sabem que os servidores da web permitem que você controle o relacionamento entre o URI de um objeto e sua localização real no sistema de arquivos. Pense em um espaço URI como um espaço abstrato, perfeitamente organizado. Em seguida, mapeie para qualquer realidade que você realmente usa para implementá-la. Em seguida, reporte-o ao servidor da web. Você pode até escrever um trecho do seu servidor para acertar.
John não mantém mais este arquivo, agora Jane mantém.
O nome de John estava no URI? Não, apenas o arquivo estava em seu diretório? Bem, ok.
Costumávamos usar um script CGI para isso, mas agora estamos usando um programa binário.
Existe uma ideia maluca de que as páginas com script devem estar localizadas na área "cgibin" ou "cgi". Isso expõe o mecanismo de como você inicia seu servidor web. Mude o mecanismo (mesmo mantendo o conteúdo) e opa - todos os seus URIs mudam.
Pegue a National Science Foundation (NSF) por exemplo: NSF
Online Documents
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 em alguns anos.
cgi-bin, oldbrowsee pl - tudo isso fornece partículas de informação sobre como-fazemos-agora. Se você usar a página para pesquisar um documento, obterá primeiro um resultado 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 próprio documento html pareça muito melhor:
http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
Aqui, o título pubs / 1998 dará a qualquer serviço de arquivamento 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, posso imaginar que esse URI ainda será válido e não interferirá com o NSF ou qualquer outra organização que manterá o arquivo de qualquer forma.
Eu não acho que os URLs deveriam ser persistentes - eles eram URNs.
Este é provavelmente um dos piores efeitos colaterais da discussão URN. Algumas pessoas pensam que, devido à pesquisa em um namespace mais persistente, podem ser descuidadas quanto a links pendentes porque "os URNs vão consertar tudo" Se você é uma dessas pessoas, deixe-me ficar desapontado.
A maioria dos esquemas URN que vi se parecem com um identificador de autoridade seguido pela data e string que você seleciona ou apenas pela string que você seleciona. Isso é muito semelhante ao URI HTTP. Em outras palavras, se você acha que sua organização será capaz de criar URNs de longa duração, prove agora usando-os para seus URIs HTTP. Não há nada no próprio HTTP que torne seu URI instável. Apenas sua organização. Crie um banco de dados que mapeie o URN do documento para o nome do arquivo atual e deixe o servidor da web usar isso para realmente recuperar os arquivos.
Se você chegou a este ponto, então se você não tem tempo, dinheiro e conexões para desenvolver algum tipo de software, então você pode dar a seguinte desculpa:
Queríamos, mas simplesmente não temos as ferramentas certas.
Mas você pode simpatizar com isso. Eu concordo totalmente. O que você precisa fazer é forçar o servidor da web a processar instantaneamente o URI persistente e retornar o arquivo onde quer que esteja armazenado em seu sistema de arquivos maluco atual. Você deseja manter todos os URIs em um arquivo como uma verificação e manter o banco de dados sempre atualizado. Você deseja preservar a relação entre diferentes versões e traduções do mesmo documento e também manter um registro independente da soma de verificação para proteger contra erros acidentais no arquivo. E os servidores web simplesmente não saem da caixa com esses recursos. Quando você deseja criar um novo documento, seu editor pede um URI.
Você precisa da capacidade de alterar a propriedade, o acesso ao documento, a segurança no nível do arquivo e assim por diante no espaço do URI sem alterar o URI.
É muito ruim. Mas vamos consertar a situação. No W3C, usamos a funcionalidade Jigedit (um servidor de edição Jigsaw) que rastreia as versões e experimentamos scripts de criação de documentos. Se você está desenvolvendo ferramentas, servidores e clientes, preste atenção neste problema!
Essa desculpa se aplica a muitas páginas do W3C também, incluindo esta: então faça o que eu digo, não o que eu faço.
Por que eu deveria me importar?
Quando você altera o URI em seu servidor, nunca pode dizer totalmente quem fará referência ao URI antigo. Podem ser links de páginas normais da web. Marcadores para sua página. O URI pode ter sido riscado na margem de uma carta para um amigo.
Quando alguém clica em um link e ele está quebrado, geralmente eles perdem a confiança no proprietário do servidor. Ele também está desapontado - tanto emocional quanto realisticamente pela incapacidade de atingir seu objetivo.
Muitas pessoas estão constantemente reclamando 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? Design URI
É responsabilidade do webmaster alocar URIs que podem ser usados em 2 anos, em 20 anos, em 200 anos. Isso requer consideração, organização e comprometimento.
Os URIs mudam se alguma informação muda neles. É muito importante como você os projeta. (O quê, design de URI? Eu preciso criar um URI? Sim, você deveria pensar sobre isso). Design significa basicamente não ter nenhuma 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 solicitações que usam o novo sistema daquelas que usam o sistema antigo. É um bom ponto de partida para um URI. Se o documento estiver datado, 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 do Money Daily na revista Money. O principal motivo pelo qual esse URI não precisa de uma data é porque não há motivo para armazenar um URI que sobreviverá ao log. O conceito de dinheiro diário desaparecerá quando o dinheiro desaparecer. Se você deseja criar um link para o conteúdo, deve incluir um link para ele separadamente nos arquivos:
http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html
(Parece bom. Presume que "dinheiro" significará a mesma coisa durante a vida do pathfinder.com. Há "98" duplicado e ".html" desnecessário, mas, por outro lado, parece um URI forte.
O que deixar de lado
Tudo! Além da data de criação, colocar qualquer informação em um URI é, de uma forma ou de outra, implorar por problemas.
- Nome do autor . A culpa pode mudar com as novas versões. As pessoas deixam as organizações e passam coisas para outras.
- Assunto . É muito difícil. Ele sempre parece bem no início, mas muda surpreendentemente rápido. Vou falar mais sobre isso a seguir.
- Status . Diretórios como "antigo", "rascunho" e assim por diante, para não mencionar "mais recente" e "legal", aparecem em todos os sistemas de arquivos. Os documentos mudam de status - caso contrário, não haveria sentido em criar rascunhos. A versão mais recente de um documento precisa de um identificador persistente, independentemente de seu status. Mantenha o status fora do nome.
- . W3C , . , , , , , . , , , - , ! .
- . . "cgi", ".html" . , 20 HTML , . W3C ( ).
- Mecanismos de software . No URI, procure "cgi", "exec" e outros termos que gritam "veja qual software estamos usando". Alguém quer devotar toda a sua vida a scripts CGI Perl? Não? Em seguida, remova a extensão .pl. Leia o manual do servidor para saber como fazer isso.
- Nome do disco. Vamos! Mas eu vi isso.
Portanto, o melhor exemplo do nosso site é simplesmente
http://www.w3.org/1998/12/01/chairs
… Um relatório da ata da reunião dos presidentes do W3C.
Tópicos e classificação por tópico
Vou entrar em mais detalhes sobre esse perigo, pois é uma das coisas mais difíceis de evitar. Normalmente, os tópicos terminam em URIs quando você categoriza seus documentos por trabalho em andamento. Mas essa divisão mudará com o tempo. Os nomes das áreas mudarão. No W3C, queríamos mudar o MarkUP para Markup e depois para HTML para refletir o conteúdo real da seção. Além disso, o namespace geralmente é simples. Após 100 anos, tem certeza de que não vai querer reutilizar nada? Em nossa curta vida, já queríamos reaproveitar "História" e "Folhas de Estilo", por exemplo.
É uma maneira tentadora de organizar um site - e uma maneira realmente tentadora de organizar qualquer coisa, incluindo a web inteira. Esta é uma excelente solução de médio prazo, mas apresenta sérias desvantagens a longo prazo.
Parte da razão está na filosofia do significado. Cada termo da linguagem é um objeto potencial de agrupamento e cada pessoa pode ter uma ideia diferente do que isso significa. Como a relação entre os sujeitos é mais parecida com uma teia de aranha do que com uma árvore, mesmo aqueles que concordam com a teia de aranha podem escolher uma representação diferente da árvore. Estas são minhas observações gerais (frequentemente repetidas) sobre os perigos da classificação hierárquica como uma solução geral.
Na verdade, quando você usa um nome de tópico em um URI, está se vinculando a algum tipo de classificação. Você pode escolher uma opção diferente no futuro. Então, o URI estará sujeito a violação.
A razão para usar uma área de assunto como parte de um URI é que a responsabilidade por subseções de um espaço de URI é geralmente delegada, caso em que você precisa do nome do corpo organizacional - uma unidade, grupo ou qualquer outro responsável por esse subespaço. Esta é a vinculação do URI à estrutura organizacional. Normalmente, só é seguro quando o URI mais abaixo (à esquerda) é protegido por uma data: 1998 / pics pode significar para o seu servidor "o que queríamos dizer em 1998 por fotos" em vez de "o que fizemos com o que agora chamamos de fotos. "
Não se esqueça do seu 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 coisas diferentes, lembre-se de que essa separação não pode ser alterada sem destruir muitos, muitos links. Alguns erros clássicos como "veja qual software estamos usando hoje" são os nomes de domínio "cgi.pathfinder.com", "seguro", "lists.w3.org". Eles são projetados para facilitar a administração do servidor. Independentemente de o domínio representar um departamento específico de sua empresa, status do documento, nível de acesso ou nível de segurança, tome 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 muitos servidores da web dentro de um servidor da web visível,usando redirecionamento e proxy.
Sim, e também pense no seu nome de domínio. Você não quer ser referido como soap.com depois de mudar sua linha de produtos e parar de fazer sabão (desculpe a quem é dono do soap.com no momento).
Conclusão
Salvar um URI por 2, 20, 200 ou mesmo 2.000 anos obviamente não é tão fácil quanto parece. No entanto, em toda a Internet, os webmasters estão tomando decisões que realmente irão dificultar para eles próprios no futuro. Muitas vezes, isso ocorre porque eles estão usando ferramentas cujo trabalho é apresentar o melhor site apenas no momento - e ninguém realmente percebeu o que aconteceria com os links quando tudo mudasse. No entanto, o ponto aqui é que muito, muito pode mudar e seus URIs podem e devem permanecer os mesmos. Isso só é possível quando você pensa em como os cria.
Veja também:
Suplementos
Como remover extensões de arquivo ...
... de um URI no servidor da web baseado em arquivo atual?
Se você estiver usando o Apache, por exemplo, você pode configurá-lo para negociar o conteúdo. Você salva a extensão do arquivo (por exemplo, .png) em um arquivo (por exemplo, mydog.png ), mas pode vincular a um recurso da web sem ela. O Apache então verifica o diretório para todos os arquivos com aquele nome e qualquer extensão, e pode escolher o melhor do conjunto (por exemplo, GIF e PNG). E você não precisa colocar diferentes tipos de arquivos em diferentes diretórios; na verdade, a negociação de conteúdo não funcionará se você fizer isso.
- Configure o seu servidor para negociar o conteúdo
- Sempre faça referência a URIs sem extensão
Os links de extensão ainda funcionarão, mas impedirão que seu servidor escolha o melhor formato disponível atualmente e no futuro.
(Na verdade,
mydog, mydog.pnge mydog.gif- os códigos e recursos da web mydog- um tipo de conteúdo de recursos universal, mydog.pnge mydog.gif- os recursos de um determinado tipo de conteúdo).
Obviamente, se você estiver escrevendo seu próprio servidor da web, é uma boa ideia usar um banco de dados para vincular IDs persistentes à sua forma atual, embora tenha cuidado com o crescimento ilimitado do banco de dados.
Shame Board - História 1: Canal 7
Durante 1999, acompanhei o fechamento de escolas devido à neve em uma 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 da minha página inicial. A primeira grande tempestade de neve de 2000 vem e eu verifico a página. Diz:
- A partir de.
Nada está fechado no momento. Por favor, volte em caso de avisos meteorológicos.
Não pode ser a mesma tempestade forte. Engraçado que faltou a data. Mas se você for para a página principal do site, haverá um grande botão "Escolas fechadas" que leva a uma 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 mudar o URI.
Shame Board - História 2: Microsoft Netmeeting
Com a crescente dependência da Internet, surgiu a ideia inteligente de aplicativos em que você pode inserir links para o site do fabricante. Isso tem sido usado e abusado muito, mas - você não pode alterar o URL. Outro dia tentei um link do cliente Microsoft Netmeeting 2 / something no menu Help / Microsoft on the Web / Free stuff e recebi um erro 404 - nenhuma resposta encontrada do servidor. Talvez já corrigido ...
© 1998 Tim BL
Nota histórica: No final do século 20, quando isso foi escrito, “cool” era um epíteto de aprovação, principalmente entre os jovens, indicando moda, qualidade ou adequação. Com pressa, o caminho do URI costumava ser escolhido por "legal" em vez de utilidade ou longevidade. Esta postagem é uma tentativa de redirecionar a energia por trás da busca pelo cool.
Veja também: