【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】
