4.1 CoAP登场与RESTful资源模型

4.1 CoAP 登场与 RESTful 资源模型

本节摘要：介绍 CoAP 的使命——给受限节点一台"小 Web 服务器"，让它们能像被网页访问一样被读写资源。本节讲清为什么用 UDP、什么是资源与端点、REST 语义如何让设备接口变得统一。承接 2.3 应用层概览，通往 4.2 的报文解剖。

HTTP 对普通服务器而言很成熟，但对一颗几 KB 内存、还要靠电池过活的单片机，完整的 HTTP 栈是奢侈品。CoAP（Constrained Application Protocol）要的就是把 Web 的优雅搬到最简陋的设备上：同样用 GET/POST/PUT/DELETE，同样暴露资源，却把报文压到很薄、并改坐在 UDP 上。

为什么 CoAP 坐在 UDP 上

CoAP 与 MQTT 截然不同的是传输选择。MQTT 坐 TCP、把可靠性外包给传输层；CoAP 坐 UDP、自己包办可靠性。这样做的红利是：无 TCP 连接状态，设备想做就做、不做就睡，省电又省内存；代价则是重传、去重、拥塞都要 CoAP 自己在应用层补，于是 CoAP 把"确认"写进了自家报文（稍后 4.2、4.3 详讲）。

一切皆资源：CoAP 的三观

CoAP 把设备抽象成一个"驻留在 coap 端点上的资源集合"。每个资源有一个 URI，例如：

• coap://dev12/temperature —— 温度资源，可 GET 读。
• coap://dev12/switch —— 开关资源，可 POST/PUT 改。
• coap://dev12/config —— 配置资源，可 POST 更新参数。

客户端往这些 URI 发方法即可读写，不用在乎设备内部细节。这种"资源化"正是 REST 的核心——用一个统一接口，把千姿百态的设备折叠成一组可预测的读写入口。

对工程师来说,把设备"资源化"的最大价值是接口可预测：温度读法只有一种，开关写法只有一种，不用每家一套私有协议。

端点到端点的直连

CoAP 原则上端点对端点（end-to-end）直连，设备既是资源服务器又是客户端，以最小的中介完成"你问我答"。相比 MQTT 必须有一台 Broker 居中撮合，CoAP 的结构天然更扁平，适合设备之间直接协作的场景（如网关轮询一组墙上的传感）。

一次最低成本的资源交互

用 GET 读一次温度，概念上长这样（4.3 会补全方法细节）：

# CoAP 资源交互示意
请求:  GET coap://dev12/temperature
响应:  2.05 Content  Payload: {"value":25.6,"unit":"celsius"}
​

这种"请求一个 URI、拿到一个表示（representation）"的模式，让 CoAP 与 HTTP 的互操作（通过代理翻译）变得顺理成章——这是 8.2 互操作演进里 CoAP 常被点名的一个原因。

💡 关键直觉：CoAP 的"资源"与软件设计里的"状态"强相关——你 GET 到的表示，往往是设备某个可观测状态的可读快照；把设备状态建模成资源，接口自然就清晰。

把"资源化"落到一棵真实设备上

接口可预测不是口号，用一个真实的小设备来验证。假设一颗水表上报的字段很多，若不做资源化，每次对接都要各家售后反复对字段表；用 CoAP 资源化之后，设备直接暴露成下面这组固定端点：

这组端点一旦约定，任何第三方客户端（物业大屏、欠费稽查、抄表平台）都用同一套 REST 格式读写，不用再猜私有协议——这就是"资源化"换来的互操作红利，也解释了为何 CoAP 在需要多厂商共用的水务、楼宇场景里受青睐。

资源交互的一次完整对话

光看端点不够，看一次真的来去。客户端要读瞬时流量，发生一次 GET：

# 客户端请求（CON，要求确认）——一次只读的 GET
请求:  GET  coap://[fd00::1]/water/usage/main
响应:  2.05 Content
       Content-Format: application/json
       Payload: {"reading":13.2,"unit":"cubic_meter"}
​

响应里除数值外还带 Content-Format 选项，声明载荷是 JSON 而非别的编码——客户端据此决定怎么解析。这个"响应自述格式"的细节，正是 REST 风格"表示（representation）可协商"的落地体现。

CoAP 直连之外的两种部署形态

说"CoAP 直连"要给它加上边界，真实部署常见两种变体：直连式（网关主动轮询墙上的楼宇传感，端点对端点），以及代理式（设备通过 6LoWPAN 或代理接入，CoAP 经代理翻译成 HTTP 让云端访问）。后一种形态让受限设备"看不见也护不着公网"，安全由代理代管。认清这两类，你才好判断在第 8 章互操作讨论里 CoAP 代理所扮演的桥梁角色。每种形态的取舍，会在 6.3 桥接实战里具体展开。

与 MQTT 的一个直观对照

MQTT 是"往主题广播，谁订阅谁知道"；CoAP 是"对一个资源点名，直接拿回结果"。前者擅长一对多解耦、可靠分发；后者擅长一对一精确读写、更省开销。选 CoAP 的常见理由是：设备数不多、交互以"读/改某状态"为主、资源受限能省则省。

本节要点回顾

• 要点一：CoAP 把 Web 的 REST 语义搬到受限节点，用统一资源接口读写设备。
• 要点二：CoAP 坐 UDP、自包可靠性，换取省电省内存，代价是自补重传去重。
• 要点三：设备被抽象成一组带 URI 的资源，GET/POST/PUT/DELETE 统一读写。
• 要点四：CoAP 原则上端点直连，结构比 MQTT（需 Broker）更扁平。
• 要点五：选 CoAP 常见在设备少、以读改为重点、资源受限的场景。

模型立住了，下一节拆开 CoAP 报文的头部字段与四类消息，看懂字节才算真懂。