Resumo

  • RFC 2068, de janeiro de 1997, definiu Link como campo de resposta HTTP para descrever uma relação entre recursos, em geral o solicitado e outro. Uma entidade podia carregar vários valores; os tipos de relação lembravam o elemento LINK do HTML.
  • RFC 5988, de outubro de 2010, registra que o campo foi retirado de RFC 2616, de junho de 1999, por falta de experiência de implementação. A omissão deixou sua posição incerta, embora alguns agentes de usuário o tenham usado depois e surgissem novos casos.
  • RFC 5988 voltou a especificar Link por meio de um modelo de relações tipadas independente do formato da página. RFC 8288, de outubro de 2017, substituiu esse texto e manteve o campo HTTP como uma forma de transportar relações entre recursos.

Um vínculo no envelope da resposta

O link impresso numa página HTML mora no documento. O navegador interpreta uma marca e decide se vai exibir ou usar a relação. Mas um recurso da web pode chegar como texto, dados estruturados ou outra representação. Se a relação estiver somente no HTML, o cliente que recebe outra forma talvez nunca a veja. O cabeçalho HTTP permite anunciá-la junto da resposta, antes da interpretação do corpo.

O RFC 2068, publicado em janeiro de 1997, ofereceu esse lugar. Sua seção 19.6.2.4 definiu Link para descrever uma relação entre dois recursos, geralmente o recurso pedido e outro. Uma entidade podia apresentar vários valores. rel indicava o tipo de relação, title um nome para leitura humana, e anchor um ponto de partida diferente. O texto comparava o campo diretamente ao elemento LINK de HTML. O aviso de que havia um recurso vizinho podia viajar no envelope da resposta, fora da página.

A mudança de posição amplia quem pode ler o aviso. Uma marca HTML serve a quem entende HTML. Um campo HTTP acompanha a resposta mesmo se o corpo tiver outro formato. O cliente que sabe lê-lo descobre a conexão sem exigir que os dados sejam uma página. O campo não entrega o recurso de destino nem determina uma ação universal. Quem decide buscá-lo ou apresentá-lo é a aplicação que reconhece a relação.

RFC 2068 colocou Link entre os recursos adicionais. Próximos dele estavam os métodos de requisição LINK e UNLINK, propostos para estabelecer e remover relações. Métodos de requisição e campo de resposta são peças diferentes. A volta posterior do cabeçalho não trouxe aqueles métodos junto. O mesmo verbo no nome não apaga a diferença entre os mecanismos.

A edição de 1999 deixou o espaço vazio

Em junho de 1999, RFC 2616 substituiu RFC 2068 sem a definição do campo Link. RFC 5988 deu a razão explicitamente: a experiência com implementações ainda era insuficiente. Os autores da revisão de HTTP/1.1 tinham uma ideia escrita, mas poucos exemplos operacionais para sustentar sua permanência no texto-base.

É uma informação sobre a decisão do padrão. Para medir quantos servidores ou clientes enviavam e entendiam Link em 1999 seriam necessários lançamentos de software datados e respostas preservadas. A documentação já mostra um limite importante da autoridade editorial: uma função pode ser especificada numa edição e perder o lugar na próxima se sua prática ainda não estiver demonstrada.

O vazio também criou custo. RFC 5988 diz que a situação do campo ficou ambígua, levando alguns a cogitar cabeçalhos específicos de cada aplicação em vez de reutilizar Link. Uma estrutura comum poderia se partir em vários nomes e regras locais. A pergunta persistia: como anunciar uma relação quando o corpo da resposta muda de formato?

O documento de 2010 relata que, depois da retirada, alguns agentes de usuário passaram a implementar o campo, por exemplo para folhas de estilo, e apareceram outras aplicações. A palavra “alguns” delimita a prova. Ela indica experiência nova, sem estabelecer uma taxa geral de adoção. Já bastava para devolver o problema à mesa de padronização.

O link retorna sem pedir passaporte HTML

RFC 5988, publicado em outubro de 2010, especificou novamente Link com sintaxe atualizada e compatível com a anterior. Também descreveu o vínculo num nível acima do formato: contexto, tipo de relação, destino e possíveis atributos do destino. A mesma relação pode aparecer num elemento HTML, num elemento Atom ou num campo HTTP. A embalagem não decide o que o vínculo significa.

A utilidade é concreta. Um recurso pode ter várias representações. Se a relação só aparecer numa versão HTML, quem pede outra versão perde o caminho. O cabeçalho consegue acompanhá-la independentemente do tipo de corpo. Isso não torna inúteis os links internos do HTML; eles seguem servindo a leitores daquele formato. O texto oferece um modelo comum, enquanto cada aplicação escolhe as relações que usa.

RFC 5988 ampliou o registro de tipos de relação que vinha do Atom e incorporou relações conhecidas no HTML. Uma relação registrada nomeia a ligação entre recursos. Não comprova que o destino esteja disponível e não obriga um cliente a segui-la. Um navegador pode querer stylesheet; uma ferramenta de arquivo pode buscar uma versão alternativa ou licença. Compartilham os nomes, mas cada uma toma sua decisão.

Em outubro de 2017, RFC 8288 substituiu RFC 5988 e conservou a estrutura de contexto, relação, alvo e atributos opcionais. Link permaneceu como uma das maneiras de transportar isso em HTTP. O documento diferencia a navegação web, que procura stylesheet no HTML e opcionalmente no cabeçalho, de uma aplicação Atom com outras relações. O tipo de relação explica como recursos se conectam; o tipo de mídia informa o formato de uma representação obtida. São questões separadas.

O retorno de 2010, portanto, foi maior que uma simples correção de 1999. O campo de 1997 projetava uma relação parecida com o LINK de HTML para o HTTP. As especificações seguintes deram aos vínculos um modelo que atravessava formatos e um registro para seus significados. A ideia voltou com uma tarefa mais bem definida.

A norma esperou mais pegadas no chão

A cronologia parece estranha se a publicação de uma RFC for confundida com implantação. Em 1997 havia uma proposta concreta; em 1999 faltava prática suficiente para conservá-la no núcleo; em 2010 surgiram implementações limitadas e novos usos para uma especificação própria; em 2017 o modelo foi revisado de novo. O editor decide o lugar de um campo no papel. O software que opera fornece a pressão que torna esse lugar defensável.

Há uma aposta além do nome. Uma relação guardada somente no corpo HTML acompanha uma representação específica. Uma relação no cabeçalho HTTP pode ser visível mesmo quando o corpo chega em outro formato. Publicador e cliente ganham um local comum para trocar conexões tipadas sem converter todos os recursos em páginas.

Para traçar a adoção por produto e ano, faltam versões datadas de clientes e servidores ou capturas de respostas. A sequência de RFCs já prova o movimento institucional: a função entrou, saiu por falta de experiência e voltou quando a necessidade de ligar recursos fora do HTML ganhou forma e exemplos.