第4章 URI与资源标识：路径设计、资源发现、/.well-known/core
4.1 概念解释
CoAP 中的 URI（统一资源标识符）是资源在设备或服务器上的唯一地址，客户端通过构造 URI 来请求具体的传感器值、开关状态或控制命令。CoAP URI 遵循 coap://host:port/path?query 的格式，其中路径部分（path）采用分层设计，斜杠（/）分隔各层级，反映资源的逻辑组织（例如：/sensors/temperature、/lights/room1/switch）。路径设计应遵循 RESTful 风格：使用名词、小写、短横线分隔复合词，避免动词。
资源发现（Resource Discovery）允许客户端在不知道具体 URI 的情况下，通过请求 /.well-known/core 获取服务器支持的资源列表。该路径是 IETF 标准定义的“核心资源”，服务器以 CoRE Link Format（RFC 6690）返回资源描述，包含 URI、接口类型（if）、媒体类型（ct）等属性。
📌 关键点： 资源发现是设备自描述的核心机制，无需固化管理地址；路径设计直接影响设备互操作性。
/.well-known/core 是一个虚拟资源，由服务器动态生成。
4.2 流程拆解：资源发现交互
- 客户端构造发现请求： GET coap://[设备地址]/.well-known/core
- 服务器响应： 返回 2.05 Content，Payload 为 CoRE Link Format 文本，格式如：
</sensors/temp>;if="sensor";ct=0, </actuators/led>;if="actuator";ct=0, </config>;if="core.p" - 客户端解析响应： 逐行读取 Link 格式，提取 URI、接口类型、内容格式。
- 可选筛选： 客户端可在 URI-Query 中加入
?if=sensor等条件，仅获取特定类型资源。 - 后续访问： 客户端根据发现的 URI 直接请求具体资源。
4.3 案例分析：智能楼宇照明系统
某智能楼宇部署了 CoAP 控制的 LED 灯组，分为楼层和房间。资源路径设计如下：
/lights– 所有灯（集合资源）/lights/{floor}– 某楼层灯（例如/lights/2f）/lights/{floor}/{room}– 某房间灯（例如/lights/2f/201）/lights/{floor}/{room}/switch– 开关状态/lights/{floor}/{room}/brightness– 亮度值
客户端通过 GET /.well-known/core 获得资源列表，解析后即可直接操作每个房间的开关和亮度。该设计层次清晰，扩展性强（增加 /sensors/lightlevel 时不影响已有资源）。
4.4 表格总结
| URI 组件 | 示例 | 说明 |
|---|---|---|
| Scheme | coap | 协议标识，可选 coaps（安全） |
| Host | 192.168.1.100 | IPv4/IPv6 地址或域名 |
| Port | 5683 | 默认 UDP 端口，可选 |
| Path | /sensors/temp | 分层资源路径，大小写敏感，建议小写 |
| Query | ?if=sensor | 过滤参数，用于资源发现筛选 |
| Fragment | #1 | CoAP 不支持碎片标识，须避免 |
| 资源发现步骤 | 动作 | 预期结果 |
|---|---|---|
| 1 | 客户端 GET /.well-known/core | 服务器返回 2.05 + Link Format 载荷 |
| 2 | 解析 Link 列表 | 提取 URI 和属性（if, ct, rt） |
| 3 | 可选按条件筛选 | 使用 ?rt=或?if=缩减响应 |
| 4 | 缓存/存储资源列表 | 用于后续操作 |
4.5 实践清单
✅ 路径设计最佳实践：
- 使用名词复数表示集合（如
/sensors），单数加 ID 表示个体（如/sensors/temp1）。 - 层数不超过 4 层，避免过深路径。
- 为每个资源定义
rt（资源类型）和if（接口类型）属性。 - 路径中禁用空格、中文、大写字母（避免歧义）。
- 资源发现响应体积随资源增多而增加，建议使用分块传输或筛选参数。
⚠️ 避坑提醒：
- 不要将敏感信息（如设备序列号）直接暴露在路径中，可通过 Query 参数传递。
- /.well-known/core 必须支持 GET 方法，但服务器可对该资源施加访问控制。
- 资源路径变更后，客户端必须重新发现，无法获知更新。