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

[[276186]]

眾所周知，REST是一種針對統(tǒng)一訪問與修改資源的架構(gòu)模式。一個實體(如服務(wù)器)持有某個對象當前狀態(tài)的權(quán)限。而其他實體可以請求當前對象的“表述(representation)”，并且可以發(fā)送創(chuàng)建、修改或刪除對象的請求。當前流行的REST模型使用URI來標識不同的對象(如“/lamp/1234”)，使用HTTP verbs來為某項指定操作，并使用JSON來表示該對象。那么為了獲取一個對象，客戶端可以發(fā)送“GET /lamp/1234”的HTTP請求。服務(wù)器可以采用HTTP 200和包含JSON數(shù)據(jù)的消息體進行響應。

目前，HTTP/JSON模型已在Web API中根深蒂固，其受歡迎的程度很自然地滲透到了物聯(lián)網(wǎng)技術(shù)之中。Samsung、Nest和Apple都發(fā)布了依賴于JSON over HTTP的API。不過，雖然REST模型適用于構(gòu)建物聯(lián)網(wǎng)這樣分布式的網(wǎng)絡(luò)，但是HTTP 1.1與JSON并不是此處的最佳選項。

JSON有什么問題?

JSON是一種基于JavaScript客戶端之間數(shù)據(jù)交互的格式，它簡化了Web應用程序。作為XML的輕量級替代品，JSON通過如下特性，成就了它在通用數(shù)據(jù)交換格式中的首選地位：

• 它是無模式(schemaless)的，也就是說：只要JSON的格式正確，就視為有效。
• JSON支持最簡單且直接的數(shù)據(jù)類型，其中包括：字符串、數(shù)字、布爾值、對象、數(shù)組和空值。
• 采用JavaScript語法表示的數(shù)據(jù)不但易讀，而且易于解析。當前各種流行的編程語言基本上都能夠支持JSON解析器。

上述功能使JSON成為了通用的格式，但是目前的物聯(lián)網(wǎng)典型用例，則可能會讓我們懷疑JSON是否適合構(gòu)成那些在智能設(shè)備環(huán)境中的嵌入式系統(tǒng)。物聯(lián)網(wǎng)設(shè)備通常需要按照如下的方式進行優(yōu)化：

• 保持網(wǎng)絡(luò)中流量盡快的小且快速。
• 最小化針對網(wǎng)絡(luò)編/解碼的原始計算量。
• 盡量使用少量的內(nèi)存和存儲空間。

在物聯(lián)網(wǎng)中，設(shè)備可能需要在小于1兆字節(jié)的內(nèi)存與存儲環(huán)境中運行，并且通常只能使用小功率的電池。而且出于功耗的考慮，它們可能一整天都連不上幾次Wi-Fi網(wǎng)絡(luò)，而每一次只能可能連接幾秒鐘。另外，就算是高端的集線器設(shè)備也不大可能擁有超過25MB的存儲空間?？梢妼τ谶@些設(shè)備而言，網(wǎng)絡(luò)方面效率是關(guān)鍵性的問題。那么為什么說JSON不是滿足上述要求的最佳選項呢?

• 盡管JSON聲稱具有精益(leanness)特征，但是它并不是一種節(jié)省空間的編碼方式。它的所有數(shù)據(jù)都被表示為ASCII字符串，而且還會添加大量的留白區(qū)域。它不但要求每個標簽字段都是完整的，而且必須對二進制數(shù)據(jù)進行轉(zhuǎn)義。何況JSON并無標準化此類處理的方法。
• 數(shù)據(jù)格式的簡單性反而引入了實現(xiàn)上的復雜性。JSON的簡單類型很難與物聯(lián)網(wǎng)編程中使用的常規(guī)類型相匹配。不同于C語言那樣能夠支持廣泛的數(shù)字類型，JSON唯一支持的只有數(shù)字型。官方的JSON規(guī)范(ECMA-404)甚至都沒有定義數(shù)字字段的最大長度。這就意味著JSON使用者必須進行大量的檢查，以確定哪一種基礎(chǔ)類型能夠與給定的數(shù)字相配。由于兩個或多個具有相同結(jié)構(gòu)、以及字段名稱的字段都可能包含不同“type”的數(shù)字，例如：字段“age”在某處可以是無符號的正整數(shù)，也可能在另一處是浮點型，因此這就增加了其自身的復雜性。
• 由于數(shù)組可以包含任意數(shù)量的類型，而且并未約束具體如何去使用某個對象中的字段，因此開發(fā)人員只能依靠約定，來確定JSON結(jié)構(gòu)會包含具體哪些數(shù)據(jù)。
• 由于在字段基本上是無序的(除了數(shù)組)，因此存在著解釋JSON數(shù)據(jù)結(jié)構(gòu)的問題。如上所述，就算是有效的JSON也可能包含了無效且無序的數(shù)據(jù)，因此那些能夠高效處理字段的策略，可能并不適用于JSON。實際上，這就意味著程序需要解析整個對象的結(jié)果，存放到本就有限的內(nèi)存之中。

既然JSON并非數(shù)據(jù)編碼的最佳技術(shù)，那么作為實現(xiàn)REST的另一半--HTTP 1.1又處于何種境地呢?

HTTP又有什么問題?

HTTP 1.1雖然為Web開發(fā)人員提供了靈活且直接的實施基礎(chǔ)，但是多年來一直困擾Web開發(fā)人員的各種HTTP錯誤，也可能會對物聯(lián)網(wǎng)的開發(fā)產(chǎn)生更大的影響。

• 由于直接將未經(jīng)任何類型壓縮的純文本字符串作為HTTP的頭部(header)，因此HTTP被視為一種臃腫的網(wǎng)絡(luò)協(xié)議。
• 最初的HTTP規(guī)范是圍繞著短平快的網(wǎng)絡(luò)連接而設(shè)計的，即：客戶端點開一個鏈接，瀏覽器請求該頁面，服務(wù)器提供之，然后關(guān)閉連接。但是，如今的網(wǎng)頁一般都需要從十幾個來源同時獲取內(nèi)容。顯然，HTTP 1.1需要在較短的一段時間內(nèi)保持連接的打開與重用。
• 物聯(lián)網(wǎng)設(shè)備在網(wǎng)絡(luò)連接的建立與耗時方面代價高昂，特別是對于SSL/TLS的協(xié)議而言，它會耗費大量的計算資源。如此反復地打開重量級的網(wǎng)絡(luò)連接，對于物聯(lián)網(wǎng)設(shè)備的有限資源而言，實在消費不起。

可見在物聯(lián)網(wǎng)領(lǐng)域，從嵌入式設(shè)備發(fā)送和接收的每一個字節(jié)都可能會影響到整體的性能。一個良好的物聯(lián)網(wǎng)協(xié)議，不僅需要能夠讓開發(fā)人員輕松地發(fā)送正確的信息，而且還能夠減輕設(shè)備及其網(wǎng)絡(luò)的負載?，F(xiàn)有的HTTP協(xié)議不但要簡化安全性、優(yōu)化傳輸流量的體積，還需要通過長期的網(wǎng)絡(luò)連接，來復用各種請求和響應。

二進制

作為一款優(yōu)秀的物聯(lián)網(wǎng)模型。REST能夠讓每個設(shè)備都能輕松地提供其狀態(tài)信息，并可以標準化數(shù)據(jù)的創(chuàng)建、讀取、更新和刪除。物聯(lián)網(wǎng)開發(fā)人員的目標就是要讓REST不再臃腫。

對于JSON來說，其物聯(lián)網(wǎng)的前景不容樂觀，目前已經(jīng)出現(xiàn)了一系列更適合編碼的替代品，例如：

• Apache Thrift和Google的Protocol Buffers(Protobuf)，都提供了更適合受限設(shè)備的二進制編碼，而且它們都具有自動化強制模式。
• CoAP是物聯(lián)網(wǎng)通信領(lǐng)域的新興標準，它定義了一種被稱為CBOR的編碼。CBOR具有自描述性，其編碼專注于產(chǎn)生體積較小的消息。
• 令人尊敬的老牌ASN.1系列編碼也在物聯(lián)網(wǎng)領(lǐng)域獲得了新生。

所有這些都提供了比JSON更適合嵌入式設(shè)備的編碼特性。

而對于HTTP來說，則面臨著更多的競爭。例如：

• CoAP定義了一種簡潔的類似REST的傳輸協(xié)議，它被譽為最可能替代HTTP 1.1的方案。
• Google的SPDY(基于TCP的會話層協(xié)議)推出了HTTP/2標準，它在某種程度上證明了HTTP是完全可以“自我改造”的。具體說來，針對上述提到的網(wǎng)絡(luò)性能問題，HTTP/2對其頭部進行了有效編碼。該協(xié)議支持連接多路復用的多個數(shù)據(jù)流，以及服務(wù)器端的啟動推送。在改造的過程中，它將SSL/TLS保持為核心部分，通過協(xié)商來保護多個數(shù)據(jù)流，減少設(shè)置開銷，并保持高安全性。
• 同樣是由Google SPDY推出的新興協(xié)議—QUIC，是針對UDP進行的TCP交換。通過消除TCP的各種連接管理開銷，QUIC減少了在網(wǎng)絡(luò)連接初建期間出現(xiàn)的延遲。

由于QUIC和HTTP/2都采用了類似的協(xié)議棧，因此兩者之間的競爭并非零和游戲，而是為了共同得到物聯(lián)網(wǎng)領(lǐng)域的認可與采用。

發(fā)展趨勢

綜上所述，雖然REST模型非常適合于物聯(lián)網(wǎng)，但是HTTP/JSON的傳統(tǒng)REST在速度、解析簡易性、面向字符串的有效負載傳輸、以及二進制編碼等方面與物聯(lián)網(wǎng)并不相配?？v觀業(yè)界，CBOR和Protobuf可以在編碼方式上替代JSON。而HTTP/2規(guī)范、及其新興的姐妹協(xié)議--QUIC，能夠有效地對HTTP起到網(wǎng)絡(luò)協(xié)議上的補充和加強作用。

原文標題：REST Without JSON: The Future of IoT Protocols，作者：Matt Butcher

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】