随着基于Web的API的兴起，我们开始将REST（具象状态传输）视为JSONoverHTTP的同义词。不出所料，JSON已取代XML作为首选的Web数据格式。虽然早期的物联网技术已经接受了JSON/HTTP组合，但这种情况很快就会改变。REST的概念会存在，但JSON和HTTP可能不再是物联网数据交换的通用语。REST的核心是一种统一访问和修改资源的架构模式。实体（服务器）是对象当前状态的权威。其他实体可以请求当前对象的“表示”，也可以发送创建、修改或删除对象的请求。当前流行的REST模型使用URI来标识对象（“/lamp/1234”），使用HTTP动词来指定操作，使用JSON来表示对象。为了获取对象，客户端可以向“GET/lamp/1234”发送HTTP请求。服务器可以使用HTTP200和包含JSON数据的正文进行响应。HTTP/JSON模型在WebAPI中根深蒂固，它的流行自然会渗透到物联网技术中。三星、Nest和苹果都发布了依赖JSONoverHTTP的API，但这种早期趋势将会消退。虽然REST模型适用于构成新物联网世界的分布式网络，但HTTP1.1和JSON却不适用。JSON有什么问题？当JavaScript传奇人物DouglasCrockford引入JSON格式时，他有兴趣指定一种格式来简化Web应用程序和基于JavaScript的客户端之间的数据交互。因为它是XML的轻量级替代品，所以JSON很快在Web开发人员中受到青睐，后来又获得了更广泛的受众。JSON的几个属性使其成为一般数据交换的理想选择。首先，它是无模式的；只要JSON格式正确，它就是有效的。其次，JSON支持最简单直接的一组数据类型：字符串、数字、布尔值、对象、数组和null。第三，数据以JavaScript语法表示，这使其既可读又易于解析。很难找到一种至少没有JSON解析器的流行编程语言。这些特性使JSON成为一种有用的通用格式，但物联网的典型用例可能会让我们质疑JSON是否适合构成智能设备环境的嵌入式系统。IoT设备通常需要通过以下方式进行优化：保持网络流量小而快。最小化网络编码和解码的原始计算。仅使用少量内存和存储空间。设备可以在不到1兆字节的内存或存储上运行，并且通常使用小电池运行。出于功耗原因，它们可能一次只能在Wi-Fi网络上停留几秒钟，有时一天只有几次。即使是高端集线器设备也不太可能拥有超过25MB的存储空间。对于这些设备，效率是关键，尤其是在网络方面。JSON不是满足这些要求的最佳选择。首先，尽管JSON声称精简，但它并不是一种节省空间的编码。所有数据都表示为ASCII字符串，通常添加大量空格。每个标签字段在每次出现时都必须完整重复。二进制数据必须转义，但是JSON没有标准的方式。这导致了JSON的第二个问题。数据格式的简单性带来了实现的复杂性。JSON的简单类型很少与IoT编程中常用的类型相匹配。虽然像C这样的语言支持范围广泛的数字类型，但JSON的唯一数字类型是数字。官方JSON规范ECMA-404甚至没有定义数字字段的最大大小。这意味着JSON消费者必须进行大量检查以查看哪种基础类型与给定数字最匹配。由于具有相同表观结构和字段名称的两个或多个字段可能包含不同的“类型”数字，这使情况变得复杂。字段“age”在一次出现时可能是无符号正整数，在另一次出现时可能是浮点数。JSON缺乏模式加剧了这个问题。数组可以包含任意数量的类型，并且对对象字段的使用方式或是否一致使用没有任何限制。开发人员完全依赖约定来确定JSON结构将包含哪些数据。最后，还有解释JSON数据结构的问题。字段基本上是无序的（数组除外）。如上所述，有效的JSON可能包含违反预期的任意数据，解析器可以解析任何给定的数据结构。高效字段级处理的策略通常不适用于JSON。实际上，这意味着解析整个对象并将结果存储在内存中。JSON显然不是数据编码的最佳技术。HTTP1.1，无处不在的REST实现的另一半，看起来也好不到哪儿去。HTTP有什么问题？HTTP1.1为Web开发人员提供了良好的服务。它灵活、直接、广泛实施，并且拥有庞大的开发人员基础。但是，困扰Web开发人员多年的HTTP错误可能会对物联网开发人员产生更大的影响。与JSON一样，HTTP也倾向于臃肿。HTTP标头就是一个很好的例子。作为未经任何压缩的纯文本字符串，它们使网络协议膨胀。网络使用是HTTP的另一个弱点。最初的HTTP规范是围绕短期网络连接的思想设计的。客户端打开一个连接，然后请求页面，服务器提供它，然后关闭连接。但是现在一般的网页可以同时抓取十几个资源。HTTP1.1引入了保持连接打开并在短时间内重用它们的功能，但HTTP仍然主要关注短期连接。考虑物联网设备的网络方面。建立连接在功率和时间方面是昂贵的，尤其是包括SSL/TLS协商；每个添加的连接都会带来大量的计算机故障。反复打开重量级网络连接是不必要的资源消耗。在物联网世界中，从嵌入式设备发送和接收的每个字节都会影响性能。一个好的物联网协议不仅可以让开发人员轻松发送正确的信息，还可以减轻设备及其网络的负担。HTTP负载模型非常适合物联网，但更好的协议可以简化安全性、优化传输大小，并专注于通过长期网络连接多路复用请求和响应。未来是二进制的REST是物联网的一个很好的模型。每个设备都可以轻松提供有关其状态的信息，并可以标准化数据的创建、读取、更新和删除方式。开发人员可以为许多物联网设备快速构建心智REST模型。获取灯泡的状态：熄灭。发送请求以将其打开。从空间加热器获取当前温度：太热了。发送较低的目标温度。该模型似乎直观地适合问题空间。但是如何处理JSON和HTTP？IoT开发人员需要REST，而不需要不必要的膨胀。物联网的未来对JSON来说是暗淡的：一系列更合适的编码填补了这个空间。ApacheThrift和Google的ProtocolBuffers(Protobuf)都提供了更适合受限设备的二进制编码，并且都具有自动强制模式的优势。CoAP是一种新兴的物联网通信标准，它定义了一种称为CBOR的编码。CBOR是自描述的，其编码侧重于生成较小的消息大小。即使是久负盛名的ASN.1编码系列也可能获得新的IoT旋转。所有这些都提供了比JSON更适合嵌入式设备的编码特性。对于HTTP，故事可能会有所不同。诚然，它将面临一些竞争；例如，CoAP定义了一个简洁的类似REST的传输协议，它是HTTP1.1的一个引人注目的替代方案。然而，随着Google的SPDY努力取得进展，HTTP/2标准表明HTTP可能已经解决了它自己的问题。HTTP/2重新显示出对网络性能的兴趣。HTTP/2中的标头经过有效编码。该协议支持在一个连接上多路复用多个数据流，以及服务器发起的推送，协议的重建将SSL/TLS作为核心部分。一次SSL/TLS协商可以保护多个数据流，减少设置开销，同时保持高度安全性。除了HTTP/2和CoAP之外，新兴的QUIC协议也可能在资源受限的设备中获得关注。QUIC，也是从SPDY中抽取出来的Google协议，用于将UDP换成TCP。通过消除TCP的一些连接管理开销，QUIC旨在减少延迟，尤其是在网络连接的初始建立期间。因为QUIC和HTTP/2基于相似的协议栈，所以两者之间的竞争不是零和游戏。两者都经过精心设计，很可能会在新兴的物联网领域获得认可。力挽狂澜REST模型非常适合物联网。然而，传统的基于HTTP的JSONREST实现充其量是不够的。在解析速度和易用性方面，JSON的面向字符串的有效负载在数据传输方面无法与二进制编码相提并论。CBOR和Protobuf等编码是JSON的有力替代品。相反，HTTP/2规范建议HTTP可能仍然是首选的应用程序协议。其新兴的姊妹协议QUIC将补充和加强物联网领域的网络协议。
