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