Кратко

  • RFC 6690 превратил модель типизированных ссылок из RFC 5988 в компактное представление application/link-format. В рамках известных URI был зарегистрирован адрес /.well-known/core как начало поиска ресурсов.
  • Ссылка может указывать тип ресурса rt, интерфейс if, формат содержимого ct и оценку максимального размера sz. Клиент вправе запросить отфильтрованный список, но серверу необязательно поддерживать фильтрацию.
  • Список направляет следующий запрос. Показание или результат даёт отдельный ответ самого ресурса. Позднее CoAP включил поиск ресурсов в модель передачи для ограниченных узлов.

У машины нет человека за стойкой

Человек может переходить по ссылкам на странице. Небольшой контроллер в системе освещения лишён экрана и сотрудника, который найдёт для него термометр или фотодатчик. RFC 6690 описывал восьмибитные микроконтроллеры и сети с малым энергопотреблением. Память и обмен данными там дороги. Если записать пути в память контроллера, замена датчика или перенос ресурса оставят старый адрес. Устройство будет стучать туда, где ответа больше нет.

Стандарт предложил известную начальную точку: /.well-known/core. Сервер, реализующий спецификацию, предоставляет этот ресурс на стандартном порту соответствующего протокола. GET возвращает тело в формате CoRE Link Format, а при отсутствии опубликованных ссылок тело может быть пустым. Пример </sensors/temp>;rt="temperature-c";if="sensor" коротко задаёт путь, тип и интерфейс. Выбрав ссылку на фотодатчик, контроллер отправляет отдельный запрос по её URI.

Первый запрос приносит карту. Второй достигает нужного устройства. Наличие ссылки не создаёт свежего показания и не будит автоматически датчик. Цель может проверить право доступа, изменить состояние или исчезнуть после публикации карты. Общий вход экономит поиск адреса, но каждый ресурс продолжает отвечать за себя.

Ссылка вышла из заголовка

RFC 5988 описал типизированную связь между контекстом и целью. RFC 6690 заимствовал запись HTTP-поля Link и сделал её самостоятельным представлением ресурса с медиатипом application/link-format. Целевой URI заключают в угловые скобки, за ним следуют атрибуты, а несколько ссылок разделяются запятыми. Небольшому устройству не требуется строить тяжёлое дерево XML ради выбора адреса. Клиент запрашивает карту как ресурс, а не ищет её среди заголовков другого ответа.

У коротких атрибутов разные задачи. rt задаёт семантический тип по словарю приложения, например измерение температуры. if описывает способ взаимодействия и может использоваться ресурсами разных типов. ct обозначает формат содержимого. sz оценивает максимальный размер представления, которое вернёт GET; устройству с малой памятью это помогает подготовить приём. rt не предназначен для человекочитаемого названия — для него существует title. Выбор адреса опирается на описание, а текущее значение узнаётся от адресата.

Если rel не указан, отношение всё равно определено: по умолчанию это hosts. Сервер, служащий контекстом ссылки, размещает цель. Явное отношение или anchor может описать другую связь, в том числе с ресурсом на ином сервере. Сбор одних URI без контекста превращает внешнее описание в якобы локальный список. Несколько знаков сохраняют сведения о том, кто заявляет о размещении ресурса.

Справочная стойка может быть маленькой

Сервер не обязан перечислять все датчики прямо в /.well-known/core. Приложение выбирает состав и порядок ссылок. Оно может объявить только коллекцию /sensors, а уже там дать ссылки на отдельные измерители. Первому посетителю не требуется передавать всю адресную книгу здания.

Клиент может сузить запрос: GET /.well-known/core?rt=light-lux ищет ресурсы определённого типа. RFC 6690 допускает фильтры, но оставляет их реализацию на усмотрение сервера. Пустой ответ требует выяснить, обработан ли фильтр, какие ссылки опубликованы и какую часть списка видит именно этот клиент. Значения rt и if — словарь приложения, а не всемирный реестр моделей устройств.

Часть датчиков спит, а узкий канал не выдержит, если каждый клиент будет обращаться ко всем узлам. RFC 6690 поэтому очертил каталог ресурсов, который хранит ссылки других серверов. Более мощный узел может дать поиск по этим копиям. Подробное поведение каталога оставлено другим спецификациям. Исходный сервер публикует описание, каталог хранит копию, клиент выбирает адрес, конечный ресурс отвечает. Копия может устареть прежде, чем клиент воспользуется ею.

У карты есть хранитель

Эта стойка сложилась из нескольких небольших договорённостей. RFC 5785 дал правило известного URI, RFC 5988 — отношения ссылок, RFC 6690 — компактное тело и общий вход для ограниченных серверов. RFC 7252 в 2014 году включил поиск ресурсов в CoAP. Был установлен способ начать разговор с каждым сервером, а не центральная книга всех датчиков мира.

Сервер решает, что показать. Он может защищать справочный адрес и выдавать разные списки в зависимости от личности запрашивающего. Но скрытая ссылка не останавливает того, кто уже знает или угадает URI: ресурс обязан проверять поступивший запрос. Если важна достоверность карты, клиенту нужна аутентификация её источника. Справочная стойка, каталог и датчик выполняют разные обязанности.

Четыре официальных текста подтверждают синтаксис, зарегистрированный адрес и предполагаемый порядок поиска. Для доказательства использования в конкретном здании нужны датированная прошивка, сохранённый ответ /.well-known/core и последующий обмен с датчиком. Контроллер из начала истории получил адрес у стойки. Показание света приходит от устройства за дверью.