【51CTO.com快譯】隨著各種基于Web的API被廣泛地在各種應用中所使用，業界經常會用到JSON/HTTP的REST(Representational State Transfer，表述性狀態傳遞)。如今，JSON早已取代了XML，成為了Web應用的首選數據格式。雖然早期的物聯網技術曾經采用過JSON/HTTP的組合，不過時過境遷，大家越來越感覺到JSON/HTTP的方式不太適合成為物聯網數據交換的通用規范。

[[276186]]

眾所周知，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】