CoAP | 物联网中的RESTful架构实现

1. HTTP—RESTful 架构的实现

说起 HTTP，相信大家都不陌生，HTTP 全称 Hyper Text Transfer Protocol，即超文本传输协议。

平常我们访问网站http://www.baidu.com/index.html，其实就是使用 HTTP 协议，获取（GET）互联网上的www.baidu.com/index.html的这个文件内容，在浏览器中显示：

在广泛使用的 HTTP 之后，还有一个巧妙的 REST 架构却鲜为人知~

REST 全称是 Representational State Transfer，中文意思是表现层状态转移，REST 指的是一组架构约束条件和原则，如果一个架构符合 REST 的约束条件和原则，我们就称它为 RESTful 架构。

REST 架构与 HTTP 之间并不能画上等号，但是目前 HTTP 是一个 REST 架构相关的实例， 所以通常描述的 REST 就是通过 HTTP 实现的 REST。

2. 对 RESTful 架构的理解

以下对 RESTful 的理解来自阮一峰的博客：理解 RESTful 架构[1]。

REST 这个词，是 Roy Thomas Fielding 在他 2000 年的博士论文中提出的，Fielding 将他对互联网软件的架构原则，定名为 REST，即 Representational State Transfer 的缩写。我对这个词组的翻译是"表现层状态转化"。

如果一个架构符合 REST 原则，就称它为 RESTful 架构。

要理解 RESTful 架构，最好的方法就是去理解 Representational State Transfer 这个词组到底是什么意思，它的每一个词代表了什么涵义。如果你把这个名称搞懂了，也就不难体会 REST 是一种什么样的设计。

资源（Resources）

REST 的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。

所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个 URI（统一资源定位符）指向它，每种资源对应一个特定的 URI。要获取这个资源，访问它的 URI 就可以，因此 URI 就成了每一个资源的地址或独一无二的识别符。

所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的 URI。

表现层（Representation）

"资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。

比如，文本可以用 txt 格式表现，也可以用 HTML 格式、XML 格式、JSON 格式表现，甚至可以采用二进制格式；图片可以用 JPG 格式表现，也可以用 PNG 格式表现。

URI 只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而 URI 应该只代表"资源"的位置。它的具体表现形式，应该在 HTTP 请求的头信息中用 Accept 和 Content-Type 字段指定，这两个字段才是对"表现层"的描述。

状态转化（State Transfer）

访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。

互联网通信协议 HTTP 协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

客户端用到的手段，只能是 HTTP 协议。具体来说，就是 HTTP 协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET 用来获取资源，POST 用来新建资源（也可以用于更新资源），PUT 用来更新资源，DELETE 用来删除资源。

综述

综合上面的解释，我们总结一下什么是 RESTful 架构：

（1）每一个 URI 代表一种资源；

（2）客户端和服务器之间，传递这种资源的某种表现层；

（3）客户端通过四个 HTTP 动词，对服务器端资源进行操作，实现"表现层状态转化"。

用一句话概括就是：

URL 用来定位资源(表现层)，HTTP 动词 (GET、POST、PUT、DELETE) 用来描述对该资源的操作。

3. 物联网中的 REST 架构实现 — CoAP

为什么要在物联网中实现 REST 架构，原因有下：

• ① 不用保持长连接

在物联网设备中，有些设备不需要保持一直在线，使用 MQTT 协议造成资源的大量浪费， 比如智能水表，智慧运输，只需要每隔一定时间将数据上报即可，所以保持一直在线没有必要；

• ② 幂等性

由于嵌入式设备的特殊性，经常容易造成断网、重启等状况，所以要保证服务器的资源无论被操作多少次之后都是一样的，不会被改变（指异常改变）；

• ③ 轻量级

嵌入式设备中存储资源和带宽都是受限的，所以协议的数据包一定要紧凑，节省，高效；

• ④ 裁剪性强

物联网设备上报数据和下发命令在出厂后可能要进行升级，协议要能方便的扩展指令或者删减指令，在 REST 架构中，这一点完全可以通过设计合适的 URI 解决。

综合以上需求，CoAP 协议诞生了，Constrained Application Protocol，即受限制的应用协议，上面这些需求，也正是 CoAP 的特点，在 CoAP 协议中：

• 使用请求/响应的通信机制（不保持长连接）；
• 使用UDP来传输数据报文（减小报文长度）；
• 通过URI来唯一确定云端资源；
• 通过PUT/POST/GET/DELETE方法对云端资源进行操作；

最后举一个生动形象的例子，比如要使用 CoAP 协议上报温度数据的设计可以是：

设备发起请求，使用 PUT 方法向 URI<服务器地址>:5683/data/temperature处的资源上传数据30，表示当前上报温度值 30，然后等待服务端的回应即可。

参考资料

理解RESTful架构: http://www.ruanyifeng.com/blog/2011/09/restful.html