Resumo

  • A RFC 6690 transformou os links tipados da RFC 5988 na representação compacta application/link-format. Ela registrou /.well-known/core sob a convenção das URIs conhecidas como ponto de partida para descobrir recursos.
  • Um link pode trazer tipo de recurso rt, interface if, formato de conteúdo ct e estimativa de tamanho máximo sz. O cliente pode pedir uma seleção filtrada, mas o servidor não precisa implementar filtros.
  • A lista aponta o próximo destino. A leitura ou o resultado chega na resposta do recurso escolhido. O CoAP incorporou depois a descoberta ao seu modelo de transferência para nós com restrições.

Máquina nenhuma chama o recepcionista

Na Web comum, uma pessoa segue links visíveis. O controlador escondido no sistema de iluminação não tem tela nem funcionário que encontre a rota até um sensor. A RFC 6690 descreveu microcontroladores de oito bits e redes de baixo consumo, onde memória e tráfego custam caro. Endereços gravados no controlador envelhecem quando um sensor é trocado ou um caminho muda. O aparelho fica pedindo a medição no antigo endereço, ainda que o novo sensor esteja funcionando.

O padrão escolheu uma porta conhecida: /.well-known/core. Um servidor que implementa o formato oferece esse recurso na porta padrão do protocolo apropriado. Um GET recebe um corpo CoRE Link Format, até mesmo um corpo vazio quando não há links publicados. O exemplo </sensors/temp>;rt="temperature-c";if="sensor" compacta caminho, tipo e interface. Ao encontrar o link de um sensor de luz, o controlador pode enviar outra requisição à URI escolhida.

Essas duas requisições fazem trabalhos diferentes. A primeira entrega um mapa; a segunda chega ao dispositivo. Um mapa pode continuar anunciando um sensor adormecido ou um recurso que exige autorização. A recepção comum tira do cliente o custo de adivinhar o começo, sem transferir para a lista a responsabilidade de produzir a medição.

Um link virou corpo de resposta

A RFC 5988 definiu um vínculo tipado entre um contexto e um destino. A RFC 6690 pegou a sintaxe do campo HTTP Link e fez dela uma representação própria, com tipo de mídia application/link-format. A URI-alvo vem entre sinais angulares, seguida de atributos; vírgulas separam descrições. É uma escrita que o nó pequeno consegue ler sem montar uma grande árvore XML. O cliente pode pedir o catálogo como recurso, sem procurar pistas no cabeçalho de outra resposta.

Os atributos curtos separam perguntas que uma tela de administração costuma misturar. rt é um tipo semântico escolhido pela aplicação: temperatura, por exemplo. if diz qual interface serve à interação e pode ser reaproveitado por tipos distintos. ct informa o formato do conteúdo. sz estima o tamanho máximo da representação devolvida por GET, ajudando um aparelho de memória curta a planejar o recebimento. rt não foi feito para ser o nome de leitura humana; o padrão reserva title para esse papel. A descrição do link ajuda a escolher o destino, e a resposta do destino resolve a pergunta sobre o dado atual.

Um link sem rel explícito não fica sem relação. O valor padrão é hosts: o servidor do contexto hospeda o alvo. Com rel ou anchor explícito, o vínculo pode dizer outra coisa e apontar até para outro servidor. Copiar apenas as URIs, descartando contexto e relação, pode transformar uma descrição externa numa falsa lista de recursos locais. Os poucos caracteres do formato carregam uma distinção de responsabilidade.

A recepção pode mostrar só o corredor

A aplicação escolhe que links entram em /.well-known/core e como eles são organizados. Pode anunciar a coleção /sensors primeiro e deixar que ela ofereça as entradas dos medidores individuais. Assim, cada pergunta inicial não obriga o servidor pequeno a despejar todos os endereços do prédio.

O cliente também pode perguntar GET /.well-known/core?rt=light-lux e pedir links de um determinado tipo. A RFC permite filtrar, mas deixa o suporte a filtros a critério do servidor. Uma lista vazia exige verificar se o servidor entendeu a seleção e quais links ele publica para aquele solicitante. rt e if são vocabulários da aplicação, não um inventário universal de modelos de dispositivos.

Alguns sensores dormem; algumas redes mal suportam consultas de todos os clientes a todos os aparelhos. A RFC esboça então um diretório de recursos que guarda links de outros servidores. Um nó com mais capacidade pode oferecer uma busca sobre essas cópias. Os detalhes do diretório ficaram fora da RFC 6690. O servidor original publica uma descrição, o diretório conserva a cópia, o cliente escolhe o endereço e o recurso responde. Uma cópia antiga pode apontar para um sensor que já mudou.

O mapa também tem quem o guarda

Quatro documentos mostram a montagem dessa porta. A RFC 5785 forneceu a convenção do caminho conhecido; a RFC 5988, a linguagem das relações; a RFC 6690, um corpo compacto para servidores restritos. Publicada em 2014, a RFC 7252 incluiu descoberta de recursos no CoAP. O acordo fixou onde começar em cada servidor, sem criar um livro central de todos os sensores do mundo.

O servidor decide o que anunciar. Pode proteger a recepção ou entregar listas diferentes conforme a identidade do cliente. Esconder um link, porém, não impede a requisição de quem já sabe ou adivinha a URI. O recurso precisa julgar o acesso quando a requisição chega. Se a origem do mapa importa, o cliente deve autenticar quem o apresentou. Recepção, diretório e sensor têm custódias diferentes.

As quatro fontes oficiais estabelecem a sintaxe, o endereço registrado e a sequência projetada. Para dizer que um prédio específico usou o formato seriam necessários firmware datado, a resposta /.well-known/core capturada e a requisição seguinte ao sensor. O controlador recebeu uma rota. O valor da luz continua vindo do aparelho atrás da porta.