Summary

  • “Cool URIs don't change” separou o endereço público do arquivo que o servidor usa para responder. A cronologia de endereçamento do W3C situa o ensaio de Tim Berners-Lee em dezembro de 1998.
  • Nomes de funcionários, pastas de CGI, extensões, estados editoriais, permissões e categorias mudam. Quando viram partes de uma URI duradoura, uma reorganização interna quebra referências que já circulam fora da instituição.

O mapa público não é a planta do escritório

Uma nova navegação pode ser boa para o visitante que entra pela página inicial. O problema aparece no visitante que volta pela porta antiga. No ensaio de 1998, Berners-Lee recusa a desculpa de que mover arquivos obrigava a mover endereços. Um servidor consegue relacionar a mesma URI a outro arquivo, outra pasta ou outro programa. A organização pode trocar a maneira de guardar o documento sem obrigar cada pessoa que o citou a atualizar a referência.

Há dois mapas em jogo. O público reúne os endereços escritos em trabalhos, salvos em favoritos e ligados por páginas independentes. O interno reúne diretórios, servidores, programas, responsáveis e controles de acesso. A equipe conhece as mudanças do mapa interno. Quem publicou um link três anos antes pode nem saber que houve obra. Transformar a mudança de um mapa em mudança do outro faz o custo sair do orçamento da reforma e aparecer no tempo de gente dispersa.

Berners-Lee reunia as justificativas que ouvia: fizemos uma reorganização para melhorar o site; os documentos antigos ficaram difíceis de classificar; foi necessário mover os arquivos; John saiu e Jane assumiu; um script CGI deu lugar a um programa binário. O trabalho aconteceu de fato. A conclusão de que a URI deve acompanhar cada etapa é uma escolha adicional. Se o endereço público não expõe a posição do arquivo ou o nome do script, o servidor pode absorver a alteração.

O caso da National Science Foundation dava corpo ao argumento. O ensaio mostrava URLs com cgi-bin, script Perl e consulta para recuperar uma publicação; comparava-as com um caminho que continha pubs/1998 e um identificador do documento. O segundo parecia mais resistente porque o ano da publicação e seu identificador podiam sobreviver ao programa usado naquele dia. Era uma comparação de projeto feita em 1998, sem medir quais dos exemplos continuariam funcionando décadas depois. O detalhe decisivo era o que o nome prometia conservar.

Berners-Lee lembrava que o operador jamais consegue listar todos os usuários de um endereço. Há links em outras páginas, marcadores pessoais e URLs anotadas fora da rede. O editor sabe onde colocou o documento novo. O leitor externo descobre a mudança ao encontrar uma falha. Essa diferença de informação torna tentador lançar o site novo e encerrar o projeto antes de testar as portas antigas.

A URI sobrevive ao organograma

Uma pasta com o nome do autor fica inadequada quando outro editor assume a página. draft envelhece quando o texto é publicado. Um caminho marcado como restrito fica estranho quando o material se torna público. A extensão .html expõe uma forma de arquivo que pode mudar. Um subdomínio batizado por uma função temporária amarra o endereço público ao arranjo de servidores do momento. O ensaio enumerava essas armadilhas para mostrar que o nome de uma coisa não precisa copiar tudo que a organização sabe sobre ela hoje.

A data de criação tem outra qualidade: um documento produzido em 1998 continuará sendo de 1998. Por isso, uma data pode ajudar a separar itens de um arquivo. Um endereço latest, por sua vez, pode nomear deliberadamente uma função que se atualiza, como a edição corrente de uma publicação. Cabe ao editor definir se o endereço identifica uma peça específica ou um lugar de atualização. O servidor pode mudar o arquivo que entrega sem confundir as duas promessas.

O assunto é mais traiçoeiro. Categorias ajudam pessoas a encontrar páginas e ajudam equipes a distribuir trabalho. Mas o vocabulário muda. Berners-Lee citou a evolução de nomes internos do próprio W3C, de “MarkUp” para “HTML”. Uma página pode permanecer a mesma enquanto a instituição muda a seção à qual ela pertence. Se o assunto está no caminho, a equipe terá de manter uma categoria antiga como endereço ou quebrar os links para adotar o nome novo. O organograma passa a disputar a identidade do documento.

Um identificador solene também precisa de manutenção

Havia quem esperasse que os Uniform Resource Names, URNs, resolvessem a permanência e liberassem os editores de cuidar das URLs comuns. Berners-Lee respondeu com uma pergunta operacional: uma instituição capaz de manter um URN duradouro já tem a disciplina necessária para manter uma URI HTTP. Nos dois casos é preciso administrar o nome, registrar a ligação com o recurso atual e fazer o servidor responder. A palavra “nome” não contrata o arquivista nem escreve a regra de encaminhamento.

O próprio ensaio admitia que as ferramentas de publicação ainda tornavam isso trabalhoso. Um editor queria manter, num mesmo registro, identificadores estáveis, localização atual, versões, traduções e somas de verificação; os servidores e programas comuns não entregavam tudo pronto. Até páginas do W3C escapavam do ideal. A confissão não desculpava a ruptura: apontava para ferramentas que permitissem trocar responsável, acesso ou armazenamento sem mudar a identidade pública.

Em 2004, a Recomendação de arquitetura da Web do W3C deu ao argumento uma formulação institucional. A persistência de uma URI depende de política e compromisso do proprietário. O esquema de identificação não oferece garantia sozinho. Respostas consistentes e redirecionamentos HTTP podem apoiar a continuidade quando o recurso muda de lugar. A decisão de mantê-la pertence ao emissor do endereço.