隨著基于Web的API的興起，我們開始認為REST(Representational State Transfer)與HTTP上的JSON同義。不出所料，JSON已取代XML作為Web的首選數據格式。雖然早期的物聯網技術已經采用了JSON / HTTP組合，但很快就會發生變化。REST的概念將存在，但JSON和HTTP可能不再是物聯網數據交換的通用語言。

[[276759]]

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將補充和加強網絡協議在物聯網領域的地位。