【.com快译】随着各种基于Web的API在各种应用中的广泛应用，业界经常使用JSON/HTTPREST（RepresentationalStateTransfer，具象状态传输）。如今，JSON早已取代XML成为Web应用程序的首选数据格式。虽然早期的物联网技术采用了JSON/HTTP的组合方式，但随着时间的推移，人们越来越觉得JSON/HTTP方式不适合成为物联网数据交换的通用规范。众所周知，REST是一种统一访问和修改资源的架构模式。实体（例如服务器）拥有对对象当前状态的控制权。还有其他实体可以请求当前对象的“表示”，并且可以发送创建、修改或删除对象的请求。当前流行的REST模型使用URI来标识不同的对象（例如“/lamp/1234”），使用HTTP动词来指定项目的操作，使用JSON来表示对象。然后为了获取对象，客户端可以发送“GET/lamp/1234”HTTP请求。服务器可以使用HTTP200和包含JSON数据的消息正文进行响应。HTTP/JSON模型现已根植于WebAPI中，其流行度自然会蔓延到物联网技术中。Samsung、Nest和Apple都发布了依赖JSONoverHTTP的API。然而，尽管REST模型适用于构建物联网等分布式网络，但HTTP1.1和JSON并不是这里的最佳选择。JSON有什么问题？JSON是一种用于基于JavaScript的客户端之间数据交互的格式，可简化Web应用程序。JSON作为XML的轻量级替代品，通过以下特点取得了其在通用数据交换格式中的首选地位：它是无模式（schemaless）的，即：只要JSON的格式正确，就被认为是有效的。JSON支持最简单直接的数据类型，包括：字符串、数字、布尔值、对象、数组和空值。使用JavaScript语法表达的数据不仅易于阅读，而且易于解析。目前，所有流行的编程语言基本上都可以支持JSON解析器。以上特点让JSON成为一种通用的格式，但目前物联网的典型用例可能会让我们质疑JSON是否适合在智能设备环境下构成嵌入式系统。IoT设备通常需要通过以下方式进行优化：使网络中的流量尽可能小和快。最小化网络编码/解码的原始计算量。尽量使用尽可能少的内存和存储空间。在物联网中，设备可能需要不到1兆字节的内存和存储才能运行，而且通常只需要低功率电池。并且出于功耗的考虑，他们一天中可能不会多次连接Wi-Fi网络，每次可能只连接几秒钟。此外，即使是高端集线器设备也不太可能拥有超过25MB的存储空间。可见，对于这些设备来说，网络效率是一个关键问题。那么为什么JSON不是满足上述要求的最佳选择呢？尽管JSON号称具有精益（leanness）特性，但它并不是一种节省空间的编码方式。它的所有数据都以ASCII字符串表示，并添加了大量的空格。它不仅要求每个标记字段都完整，而且二进制数据也必须进行转义。更何况JSON并没有对这样的处理方式进行标准化。数据格式的简单性引入了实现的复杂性。JSON的简单类型很难与物联网编程中使用的常规类型相匹配。与C语言可以支持范围广泛的数值类型不同，JSON只支持数值类型。官方JSON规范(ECMA-404)甚至没有定义数字字段的最大长度。这意味着JSON消费者必须进行大量检查以查看哪个基础类型与给定数字匹配。由于两个或多个具有相同结构和字段名称的字段可能包含不同“类型”的数字，例如：“年龄”字段在一个地方可以是无符号正整数，而在另一个点类型是浮点数，所以这增加了其自身的复杂性。因为数组可以包含任意数量的类型，并且对如何使用对象中的字段没有限制，开发人员只能依靠约定来确定JSON结构将包含哪些数据。由于字段基本上是无序的（数组除外），因此在解释JSON数据结构时存在问题。如上所述，即使是有效的JSON也可能包含无效和无序的数据，因此有效处理字段的策略可能不适用于JSON。实际上，这意味着程序需要解析整个对象的结果并将其存储在已经有限的内存中。既然JSON并不是最好的数据编码技术，那么REST的另一半HTTP1.1的现状如何呢？HTTP有什么问题？HTTP1.1为Web开发人员提供了灵活直接的实现基础，但困扰Web开发人员多年的同种HTTP错误也可能对物联网开发产生更大的影响。由于直接使用未经任何类型压缩的纯文本字符串作为HTTP头（header），因此HTTP被认为是一个臃肿的网络协议。最初的HTTP规范是围绕短、扁平、快速的网络连接设计的：客户端单击链接，浏览器请求页面，服务器提供页面，然后关闭连接。然而，今天的网页通常同时从十几个来源获取内容。显然，HTTP1.1要求连接在短时间内保持打开和重用。物联网设备在网络连接建立和耗时方面成本高昂，尤其是对于SSL/TLS协议，会消耗大量计算资源。像这样反复打开重量级网络连接对于IoT设备的有限资源来说太昂贵了。可见，在物联网领域，嵌入式设备发送和接收的每一个字节都可能影响整体性能。一个好的物联网协议不仅需要让开发人员能够轻松发送正确的信息，还可以减轻设备及其网络的负载。现有的HTTP协议不仅需要简化安全和优化传输流量，还需要通过长期的网络连接来复用各种请求和响应。Binary是一个优秀的物联网模型。REST使每个设备都能轻松提供有关其状态的信息，并标准化数据的创建、读取、更新和删除。IoT开发人员的目标是让REST不那么臃肿。对于JSON来说，它在物联网领域的前景不容乐观。出现了一系列更适合编码的替代方案，例如：ApacheThrift和Google的ProtocolBuffers(Protobuf)，它们都提供了更适合受限设备的二进制编码，并且它们都具有自动执行模式。CoAP是物联网通信领域的新兴标准，它定义了一种称为CBOR的编码。CBOR是自描述的，其编码侧重于生成小尺寸的消息。古老的ASN.1编码系列也在物联网领域获得新生。所有这些都提供了比JSON更适合嵌入式设备的编码特性。对于HTTP，它面临更多的竞争。例如：CoAP定义了一个简洁的类REST传输协议，被誉为最有可能替代HTTP1.1。Google的SPDY（基于TCP的会话层协议）推出了HTTP/2标准，从某种程度上证明了HTTP完全可以“自我改造”。具体来说，针对上述网络性能问题，HTTP/2对其头部进行了有效的编码。该协议支持连接多路复用多个数据流，以及服务器端发起的推送。在转型过程中，它以SSL/TLS为核心，协商保护多个数据流，减少设置开销，保持高安全性。同样由??GoogleSPDY推出的新兴协议QUIC是UDP的TCP交换。通过消除TCP的各种连接管理开销，QUIC减少了网络连接初始建立期间发生的延迟。由于QUIC和HTTP/2都使用相似的协议栈，因此两者之间的竞争不是零和游戏，而是为了在物联网领域获得共同认可和采用。趋势总之，虽然REST模型非常适合物联网，但传统的基于HTTP/JSON的REST在速度、易解析性、面向字符串的有效负载传输和二进制编码方面并不适合物联网。纵观整个行业，CBOR和Protobuf在编码方式上可以替代JSON。HTTP/2规范及其新兴的姊妹协议QUIC可以有效地补充和加强HTTP作为网络协议。原标题：RESTWithoutJSON:TheFutureofIoTProtocols，作者：MattButcher
