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