摘要

  • RFC 6690 把 RFC 5988 的 Web Linking 思路做成 application/link-format 资源表示，并依照 RFC 5785 登记 /.well-known/core，让受限服务器有一个约定好的资源发现入口。
  • 清单里的链接可用 rt 标资源类型、if 标接口、ct 标内容格式、sz 标最大尺寸估计。客户端可以带条件寻找，服务器却不必支持过滤；服务器也可以只列集合入口，让客户端继续往下找。
  • 发现清单解决“往哪里请求”，目标资源的下一次响应才给出读数或执行结果。CoAP 规范 后来把资源发现纳入受限节点的传输模型。

没有人的前台

人在网页上可以看着链接一路点。楼宇里的小控制器没有屏幕，也没有值班员替它翻目录。它想取光照、温度，或者找到一只开关，就得从网络上识别资源入口。RFC 6690 所描述的环境有八位微控制器和低功耗网络；内存、报文和等待时间都不是免费的。路径若写死在控制器里，换一台传感器或调整一条资源路径，就可能让控制器拿着旧门牌继续敲门。

规范为此选了一个固定地址：/.well-known/core。实现该规范的服务器在相应协议的默认端口提供这个资源。GET 的回答是一份 CoRE Link Format 链接清单；若没有可列的链接，载荷可以为空。规范示例里，</sensors/temp>;rt="temperature-c";if="sensor" 用很短的文本把目标路径、资源类型和接口描述放在一起。客户端可以在同一张清单里找到光照传感器，然后向选中的路径另发请求。

这两次请求不能压成一件事。第一次拿地图，第二次抵达设备。地图里有光照入口，不代表传感器此刻在线、读数已经产生，或者这个客户端有权操作它。目录的价值恰在于把寻找入口的步骤集中到一个共同位置，同时让各资源继续在自己的地址回答。

链接从响应头搬进了正文

RFC 5988 给 Web Linking 定义了上下文、关系和目标。RFC 6690 借用了 HTTP Link 字段的写法，却把链接作为资源表示返回，媒体类型为 application/link-format。一个目标放在尖括号里，后面跟属性；多个描述以逗号隔开。小设备能处理这份紧凑文本，不必为了发现一只传感器先建起厚重的目录解析器。服务器提供的是可请求的资源内容，而不是要客户端从其他响应头里捡线索。

几个短属性各司其职。rt 是应用选定的资源类型，像在说“这是一份温度读数”；if 描述交互接口，同一种接口可以服务不同资源类型；ct 指内容格式；sz 估计 GET 后可能得到的最大表示尺寸，内存有限的客户端可据此决定怎样接收。rt 不是给人看的显示名称，标准把这个用途留给 title。把这些属性统统叫作“设备身份”，就抹掉了类型、操作方式与传输成本之间的区别。

还有一个容易漏掉的默认值：链接若没有显式 rel，关系就是 hosts，意思是链接的上下文服务器托管目标。显式关系和 anchor 又可以描述别的联系，目标甚至可能在另一台服务器上。若有人只收集 URI，丢掉关系和上下文，就可能把外部描述当作本机托管资源。少量字节承担的是路由含义，不是装饰。

清单可以很短

规范没有要求每台小设备把所有传感器一次倒在前台。应用自己决定 /.well-known/core 列哪些链接、怎样组织。它可以只给 /sensors 集合入口，再让客户端在集合资源里取得温度和光照成员。这样每次有人问路，受限节点不必先把整座楼的门牌搬出来。

想找特定资源的客户端还能带上查询：GET /.well-known/core?rt=light-lux 请求资源类型为 light-lux 的链接。RFC 6690 允许服务器支持这种过滤，但没有强制要求。客户端看见一份空结果，要先弄清服务器是否实施了过滤；否则“没找到”只是一次查询的结果，不是楼里没有光照传感器的证据。资源类型和接口描述是应用约定的词汇，并非全球每款设备的统一型号表。

有些设备会休眠；有些链路经不起每个客户端都去问所有端点。RFC 6690 因而勾勒资源目录：能力更强的节点可以收集其他服务器的链接，代为提供可查询的视图。完整的目录功能留给后续规范。这里形成一条清楚的保管链：受限节点发布自己的描述，目录保存并展示副本，客户端选择路径，目标资源最后回答。若目录信息过时，必须回到目标的实际交互才能发现。

地图也有保管人

这一设计把几项小协议拼得恰到好处。RFC 5785 提供约定路径的框架，RFC 5988 提供类型化链接的语法，RFC 6690 给受限服务器压缩成载荷和共同入口。2014 年的 RFC 7252 又把资源发现放进 CoAP 面向受限节点的模型里。它们没有建一个总揽全世界传感器的中央注册处，而是让客户端知道从每台服务器的哪里开始问。

服务器控制自己列出的链接。它可以按请求者身份给出不同清单，也可以保护发现入口。但只把某个 URI 藏起来，挡不住已经知道或猜到路径的人；实际资源仍须在请求到来时执行自己的访问控制。若链接来源不可信，客户端还得验证提供清单的是谁。目录管理员、设备管理员和客户端各有一段工作，不能因为都在一张地图上就算成同一位主人。

官方文本证明了语法、入口与预期的两步发现流程。要证明某栋楼实际采用过它，需要那套设备的固件版本、当时的 /.well-known/core 响应和随后对传感器的请求记录。开头那只控制器从小前台拿到了门牌。光照读数仍要由门后的传感器交出来。