|
|
51CTO旗下网站
|
|
移动端

未来物联网协议:不带JSON的REST

本文分析了HTTP/JSON的传统REST不适合物联网技术的原因,并指出了新的协议发展方向。

作者:陈峻编译来源:51CTO|2019-09-09 08:00

【51CTO.com快译】随着各种基于Web的API被广泛地在各种应用中所使用,业界经常会用到JSON/HTTP的REST(Representational State Transfer,表述性状态传递)。如今,JSON早已取代了XML,成为了Web应用的首选数据格式。虽然早期的物联网技术曾经采用过JSON/HTTP的组合,不过时过境迁,大家越来越感觉到JSON/HTTP的方式不太适合成为物联网数据交换的通用规范。

众所周知,REST是一种针对统一访问与修改资源的架构模式。一个实体(如服务器)持有某个对象当前状态的权限。而其他实体可以请求当前对象的“表述(representation)”,并且可以发送创建、修改或删除对象的请求。当前流行的REST模型使用URI来标识不同的对象(如“/lamp/1234”),使用HTTP verbs来为某项指定操作,并使用JSON来表示该对象。那么为了获取一个对象,客户端可以发送“GET /lamp/1234”的HTTP请求。服务器可以采用HTTP 200和包含JSON数据的消息体进行响应。

目前,HTTP/JSON模型已在Web API中根深蒂固,其受欢迎的程度很自然地渗透到了物联网技术之中。Samsung、Nest和Apple都发布了依赖于JSON over HTTP的API。不过,虽然REST模型适用于构建物联网这样分布式的网络,但是HTTP 1.1与JSON并不是此处的最佳选项。

JSON有什么问题?

JSON是一种基于JavaScript客户端之间数据交互的格式,它简化了Web应用程序。作为XML的轻量级替代品,JSON通过如下特性,成就了它在通用数据交换格式中的首选地位:

  • 它是无模式(schemaless)的,也就是说:只要JSON的格式正确,就视为有效。
  • JSON支持最简单且直接的数据类型,其中包括:字符串、数字、布尔值、对象、数组和空值。
  • 采用JavaScript语法表示的数据不但易读,而且易于解析。当前各种流行的编程语言基本上都能够支持JSON解析器。

上述功能使JSON成为了通用的格式,但是目前的物联网典型用例,则可能会让我们怀疑JSON是否适合构成那些在智能设备环境中的嵌入式系统。物联网设备通常需要按照如下的方式进行优化:

  • 保持网络中流量尽快的小且快速。
  • 最小化针对网络编/解码的原始计算量。
  • 尽量使用少量的内存和存储空间。

在物联网中,设备可能需要在小于1兆字节的内存与存储环境中运行,并且通常只能使用小功率的电池。而且出于功耗的考虑,它们可能一整天都连不上几次Wi-Fi网络,而每一次只能可能连接几秒钟。另外,就算是高端的集线器设备也不大可能拥有超过25MB的存储空间。可见对于这些设备而言,网络方面效率是关键性的问题。那么为什么说JSON不是满足上述要求的最佳选项呢?

  • 尽管JSON声称具有精益(leanness)特征,但是它并不是一种节省空间的编码方式。它的所有数据都被表示为ASCII字符串,而且还会添加大量的留白区域。它不但要求每个标签字段都是完整的,而且必须对二进制数据进行转义。何况JSON并无标准化此类处理的方法。
  • 数据格式的简单性反而引入了实现上的复杂性。JSON的简单类型很难与物联网编程中使用的常规类型相匹配。不同于C语言那样能够支持广泛的数字类型,JSON唯一支持的只有数字型。官方的JSON规范(ECMA-404)甚至都没有定义数字字段的最大长度。这就意味着JSON使用者必须进行大量的检查,以确定哪一种基础类型能够与给定的数字相配。由于两个或多个具有相同结构、以及字段名称的字段都可能包含不同“type”的数字,例如:字段“age”在某处可以是无符号的正整数,也可能在另一处是浮点型,因此这就增加了其自身的复杂性。
  • 由于数组可以包含任意数量的类型,而且并未约束具体如何去使用某个对象中的字段,因此开发人员只能依靠约定,来确定JSON结构会包含具体哪些数据。
  • 由于在字段基本上是无序的(除了数组),因此存在着解释JSON数据结构的问题。如上所述,就算是有效的JSON也可能包含了无效且无序的数据,因此那些能够高效处理字段的策略,可能并不适用于JSON。实际上,这就意味着程序需要解析整个对象的结果,存放到本就有限的内存之中。

既然JSON并非数据编码的最佳技术,那么作为实现REST的另一半--HTTP 1.1又处于何种境地呢?

HTTP又有什么问题?

HTTP 1.1虽然为Web开发人员提供了灵活且直接的实施基础,但是多年来一直困扰Web开发人员的各种HTTP错误,也可能会对物联网的开发产生更大的影响。

  • 由于直接将未经任何类型压缩的纯文本字符串作为HTTP的头部(header),因此HTTP被视为一种臃肿的网络协议。
  • 最初的HTTP规范是围绕着短平快的网络连接而设计的,即:客户端点开一个链接,浏览器请求该页面,服务器提供之,然后关闭连接。但是,如今的网页一般都需要从十几个来源同时获取内容。显然,HTTP 1.1需要在较短的一段时间内保持连接的打开与重用。
  • 物联网设备在网络连接的建立与耗时方面代价高昂,特别是对于SSL/TLS的协议而言,它会耗费大量的计算资源。如此反复地打开重量级的网络连接,对于物联网设备的有限资源而言,实在消费不起。

可见在物联网领域,从嵌入式设备发送和接收的每一个字节都可能会影响到整体的性能。一个良好的物联网协议,不仅需要能够让开发人员轻松地发送正确的信息,而且还能够减轻设备及其网络的负载。现有的HTTP协议不但要简化安全性、优化传输流量的体积,还需要通过长期的网络连接,来复用各种请求和响应。

二进制

作为一款优秀的物联网模型。REST能够让每个设备都能轻松地提供其状态信息,并可以标准化数据的创建、读取、更新和删除。物联网开发人员的目标就是要让REST不再臃肿。

对于JSON来说,其物联网的前景不容乐观,目前已经出现了一系列更适合编码的替代品,例如:

  • Apache Thrift和Google的Protocol Buffers(Protobuf),都提供了更适合受限设备的二进制编码,而且它们都具有自动化强制模式。
  • CoAP是物联网通信领域的新兴标准,它定义了一种被称为CBOR的编码。CBOR具有自描述性,其编码专注于产生体积较小的消息。
  • 令人尊敬的老牌ASN.1系列编码也在物联网领域获得了新生。

所有这些都提供了比JSON更适合嵌入式设备的编码特性。

而对于HTTP来说,则面临着更多的竞争。例如:

  • CoAP定义了一种简洁的类似REST的传输协议,它被誉为最可能替代HTTP 1.1的方案。
  • Google的SPDY(基于TCP的会话层协议)推出了HTTP/2标准,它在某种程度上证明了HTTP是完全可以“自我改造”的。具体说来,针对上述提到的网络性能问题,HTTP/2对其头部进行了有效编码。该协议支持连接多路复用的多个数据流,以及服务器端的启动推送。在改造的过程中,它将SSL/TLS保持为核心部分,通过协商来保护多个数据流,减少设置开销,并保持高安全性。
  • 同样是由Google SPDY推出的新兴协议—QUIC,是针对UDP进行的TCP交换。通过消除TCP的各种连接管理开销,QUIC减少了在网络连接初建期间出现的延迟。

由于QUIC和HTTP/2都采用了类似的协议栈,因此两者之间的竞争并非零和游戏,而是为了共同得到物联网领域的认可与采用。

发展趋势

综上所述,虽然REST模型非常适合于物联网,但是HTTP/JSON的传统REST在速度、解析简易性、面向字符串的有效负载传输、以及二进制编码等方面与物联网并不相配。纵观业界,CBOR和Protobuf可以在编码方式上替代JSON。而HTTP/2规范、及其新兴的姐妹协议--QUIC,能够有效地对HTTP起到网络协议上的补充和加强作用。

原文标题:REST Without JSON: The Future of IoT Protocols,作者:Matt Butcher

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

【编辑推荐】

  1. 随着物联网市场不断发展和成熟 有哪些新的机遇和挑战
  2. 人工智能和物联网如何成为完美一对
  3. 物联网在交通运输中的好处:行业案例研究
  4. 物联网的安全挑战有哪些?
  5. 浅谈:物联网的过去、现在和未来
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

用Python玩转excel

用Python玩转excel

让重复操作傻瓜化
共3章 | DE8UG

119人订阅学习

AI入门级算法

AI入门级算法

算法常识
共22章 | 周萝卜123

113人订阅学习

这就是5G

这就是5G

5G那些事儿
共15章 | armmay

120人订阅学习

读 书 +更多

精通JavaScript动态网页编程(实例版)

本书通过大量实例代码,以ECMA-262版本3为基础,结合JavaScript 1.5和JavaScript 5.5,由浅入深、循序渐进地介绍了JavaScript知识要点与编...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微