中文字幕日韩精品一区二区免费_精品一区二区三区国产精品无卡在_国精品无码专区一区二区三区_国产αv三级中文在线

JSON / HTTP模型可能不適合物聯(lián)網(wǎng)技術(shù)

2021-01-27    分類: 網(wǎng)站建設(shè)

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

REST的核心是統(tǒng)一訪問和修改資源的架構(gòu)模式。一個實(shí)體(服務(wù)器)是對象當(dāng)前狀態(tài)的權(quán)限。其他實(shí)體可以請求當(dāng)前對象的“表示”,并且還可以發(fā)送創(chuàng)建,修改或刪除對象的請求。當(dāng)前流行的REST模型使用URI來標(biāo)識對象(“/ lamp / 1234”),使用HTTP謂詞來指定操作,使用JSON來表示對象。為了獲取對象,客戶端可以向“GET / lamp / 1234”發(fā)送HTTP請求。服務(wù)器可以用HTTP 200和包含JSON數(shù)據(jù)的主體進(jìn)行響應(yīng)。

HTTP / JSON模型在Web API中根深蒂固,其受歡迎程度自然會滲透到物聯(lián)網(wǎng)技術(shù)中。三星,Nest和Apple都發(fā)布了依賴于JSON over HTTP的API,但這種早期趨勢將會消退。雖然REST模型適用于構(gòu)成新物聯(lián)網(wǎng)世界的分布式網(wǎng)絡(luò),但HTTP 1.1和JSON并不合適。

JSON存在什么問題?

當(dāng)JavaScript傳奇人物Douglas Crockford介紹JSON格式時,他有興趣指定一種簡化Web應(yīng)用程序和基于JavaScript的客戶端之間數(shù)據(jù)交互的格式。因?yàn)樗荴ML的輕量級替代品,所以JSON很快在Web開發(fā)人員中獲得了吸引力,并且后來達(dá)到了更普遍的受眾。

JSON的幾個特性使其成為通用數(shù)據(jù)交換的理想選擇。首先,它是無模式的; 只要JSON格式正確,它就是有效的。其次,JSON支持一組最簡單直接的數(shù)據(jù)類型:字符串,數(shù)字,布爾值,對象,數(shù)組和空值。第三,數(shù)據(jù)以JavaScript語法表示,這使得它既易讀又易于解析。人們很難找到一種沒有至少一個JSON解析器的流行編程語言。

這些功能使JSON成為一種有用的通用格式,但物聯(lián)網(wǎng)的典型用例可能會讓我們懷疑JSON是否適合構(gòu)成智能設(shè)備環(huán)境的嵌入式系統(tǒng)。物聯(lián)網(wǎng)設(shè)備通常需要按以下方式進(jìn)行優(yōu)化:

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

設(shè)備可能以小于1兆字節(jié)的內(nèi)存或存儲運(yùn)行,并且通常使用小型電池運(yùn)行。出于功耗原因,它們可能一次僅在Wi-Fi網(wǎng)絡(luò)上幾秒鐘,有時一天只有幾次。即使是高端集線器設(shè)備也不太可能擁有超過25MB的存儲空間。對于這些設(shè)備,效率是關(guān)鍵,特別是在網(wǎng)絡(luò)方面。

JSON不是滿足這些要求的好候選者。首先,盡管JSON聲稱具有精益,但它并不是一種節(jié)省空間的編碼。所有數(shù)據(jù)都表示為ASCII字符串,通常添加了大量的空白區(qū)域。每次出現(xiàn)時,每個標(biāo)簽字段必須完整重復(fù)。必須對二進(jìn)制數(shù)據(jù)進(jìn)行轉(zhuǎn)義,但在JSON中沒有標(biāo)準(zhǔn)方法。

這導(dǎo)致了JSON的第二個問題。數(shù)據(jù)格式的簡單性引入了實(shí)現(xiàn)的復(fù)雜性。JSON的簡單類型很少與IoT編程中通常使用的類型相匹配。雖然像C這樣的語言支持廣泛的數(shù)字類型,但JSON唯一的數(shù)字類型是數(shù)字。官方JSON規(guī)范ECMA-404甚至沒有定義數(shù)字字段的大大小。這意味著JSON使用者必須進(jìn)行大量檢查以確定哪種基礎(chǔ)類型與給定數(shù)字最匹配。由于兩個或多個具有相同表觀結(jié)構(gòu)和字段名稱的字段可能包含不同的“類型”數(shù)字,因此這很復(fù)雜。字段“age”在一次出現(xiàn)時可以是無符號正整數(shù),而在另一種情況下可以是浮點(diǎn)。

JSON缺乏架構(gòu)加劇了這個問題。數(shù)組可以包含任意數(shù)量的類型,并且對于如何使用對象的字段或是否一致地使用它們沒有約束。開發(fā)人員僅依靠約定來確定JSON結(jié)構(gòu)將包含哪些數(shù)據(jù)。最后,存在解釋JSON數(shù)據(jù)結(jié)構(gòu)的問題。字段基本上是無序的(除了數(shù)組)。如上所述,有效JSON可能包含違反期望的任意數(shù)據(jù),解析器可以解決任何給定的數(shù)據(jù)結(jié)構(gòu)。用于高效字段級處理的策略通常不適用于JSON。實(shí)際上,這意味著解析整個對象并將結(jié)果存儲在內(nèi)存中。

JSON顯然不是數(shù)據(jù)編碼的好技術(shù)。HTTP 1.1,無處不在的REST實(shí)現(xiàn)的另一半,看起來并沒有更好看。

HTTP存在什么問題?

HTTP 1.1為Web開發(fā)人員提供了很好的服務(wù) 它靈活,直接,廣泛實(shí)施,并擁有龐大的開發(fā)人員基礎(chǔ)。但是,多年來讓網(wǎng)絡(luò)開發(fā)人員煩惱的HTTP錯誤可能對物聯(lián)網(wǎng)開發(fā)人員產(chǎn)生更大的影響。

與JSON一樣,HTTP傾向于臃腫的一面。HTTP標(biāo)頭就是一個很好的例子。作為沒有任何類型壓縮的純文本字符串,它們會膨脹網(wǎng)絡(luò)協(xié)議。

網(wǎng)絡(luò)使用是HTTP的另一個不足之處。最初的HTTP規(guī)范是圍繞短期網(wǎng)絡(luò)連接的想法而設(shè)計的??蛻舳舜蜷_一個連接,然后請求頁面,服務(wù)器提供它,連接關(guān)閉。但是現(xiàn)在平均網(wǎng)頁可以同時獲取十幾個資源。HTTP 1.1引入了一些功能,可以在短時間內(nèi)保持連接打開和重用,但HTTP基本上仍然專注于短期連接。

考慮物聯(lián)網(wǎng)設(shè)備的網(wǎng)絡(luò)方面。建立連接在功率和時間方面是昂貴的,特別是包括ssl / TLS協(xié)商; 每個添加的連接帶來了大量的計算機(jī)打擊。反復(fù)打開重量級網(wǎng)絡(luò)連接是不必要的資源消耗。

在物聯(lián)網(wǎng)領(lǐng)域,從嵌入式設(shè)備發(fā)送和接收的每個字節(jié)都會影響性能。良好的物聯(lián)網(wǎng)協(xié)議不僅使開發(fā)人員能夠輕松發(fā)送正確的信息,而且還減輕了設(shè)備及其網(wǎng)絡(luò)的負(fù)擔(dān)。HTTP有效載荷模型非常適合物聯(lián)網(wǎng),但更好的協(xié)議可以簡化安全性,優(yōu)化傳輸大小,并專注于通過長期網(wǎng)絡(luò)連接復(fù)用請求和響應(yīng)。

未來是二元的

REST是物聯(lián)網(wǎng)的一個很好的模型。每個設(shè)備都可以輕松地提供其狀態(tài)信息,并可以標(biāo)準(zhǔn)化創(chuàng)建,讀取,更新和刪除該數(shù)據(jù)的方式。開發(fā)人員可以快速為許多物聯(lián)網(wǎng)設(shè)備構(gòu)建mental REST模型。獲取燈泡的狀態(tài):它已關(guān)閉。發(fā)送請求將其打開。從空間加熱器獲取當(dāng)前溫度:它太熱了。發(fā)送較低的目標(biāo)溫度。該模型似乎直觀地匹配問題空間。

但是關(guān)于JSON和HTTP要做什么呢?物聯(lián)網(wǎng)開發(fā)人員需要REST而不會出現(xiàn)不必要的膨脹。

對于JSON來說,物聯(lián)網(wǎng)的未來是黯淡的:一系列更適合的編碼充斥著空間。Apache Thrift和Google的協(xié)議緩沖區(qū)(Protobuf)都提供了更適合受限設(shè)備的二進(jìn)制編碼,并且都具有自動強(qiáng)制模式的優(yōu)勢。CoAP是物聯(lián)網(wǎng)通信的新興標(biāo)準(zhǔn),它定義了一種稱為CBOR的編碼。CBOR是自描述的,編碼專注于產(chǎn)生小的消息大小。即使是令人尊敬的ASN.1系列編碼也可能會獲得新的IoT旋轉(zhuǎn)。所有這些都提供了比JSON更適合嵌入式設(shè)備的編碼特性。

對于HTTP,故事可能會有不同的表現(xiàn)。沒錯,它將面臨一些競爭; 例如,CoAP定義了一個簡潔的類似REST的傳輸協(xié)議,它是HTTP 1.1的一個引人注目的替代方案。但是,隨著Google的SPDY努力的發(fā)展,HTTP / 2標(biāo)準(zhǔn)表明HTTP可能已經(jīng)解決了自己的問題。

HTTP / 2顯示出對網(wǎng)絡(luò)性能的新興趣。HTTP / 2中的標(biāo)頭是有效編碼的。該協(xié)議支持通過一個連接多路復(fù)用多個數(shù)據(jù)流,以及服務(wù)器啟動的推送,協(xié)議的重建將ssl / TLS保持為中心部分。然后,一個ssl / TLS協(xié)商可以保護(hù)多個數(shù)據(jù)流,從而減少設(shè)置開銷,但保持高度的安全性。

除了HTTP / 2和CoAP之外,新興的QUIC協(xié)議也可能在資源受限的設(shè)備中獲得吸引力。QUIC,也是從SPDY繪制的Google協(xié)議,用于交換TCP的UDP。通過消除TCP的一些連接管理開銷,QUIC旨在減少延遲,尤其是在初始建立網(wǎng)絡(luò)連接期間。

因?yàn)镼UIC和HTTP / 2基于類似的協(xié)議棧,所以兩者之間的競爭不是零和游戲。兩者都經(jīng)過精心設(shè)計,很可能在新興的物聯(lián)網(wǎng)領(lǐng)域獲得認(rèn)可。

轉(zhuǎn)向潮流

REST模型非常適合物聯(lián)網(wǎng)。但是,傳統(tǒng)的基于HTTP的JSON REST實(shí)現(xiàn)充其量是不合適的。在速度和解析簡易性方面,JSON的面向字符串的有效負(fù)載在數(shù)據(jù)傳輸方面與二進(jìn)制編碼不匹配。像CBOR和Protobuf這樣的編碼是JSON的引人注目的替代品。

相反,HTTP / 2規(guī)范表明HTTP可能仍然是所選的應(yīng)用程序協(xié)議。其新興的姐妹協(xié)議QUIC將補(bǔ)充和加強(qiáng)網(wǎng)絡(luò)協(xié)議在物聯(lián)網(wǎng)領(lǐng)域的地位。

網(wǎng)站標(biāo)題:JSON / HTTP模型可能不適合物聯(lián)網(wǎng)技術(shù)
網(wǎng)頁URL:http://m.rwnh.cn/news6/97756.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)頁設(shè)計公司、建站公司、服務(wù)器托管用戶體驗(yàn)、動態(tài)網(wǎng)站域名注冊

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)

網(wǎng)站優(yōu)化排名
永安市| 曲麻莱县| 永宁县| 汉中市| 林口县| 保亭| 吕梁市| 靖西县| 曲水县| 娄底市| 安陆市| 大埔县| 瑞安市| 保山市| 平泉县| 葫芦岛市| 霍城县| 南陵县| 盐津县| 什邡市| 青铜峡市| 天柱县| 滨州市| 衡水市| 健康| 敖汉旗| 怀宁县| 资源县| 华容县| 遂宁市| 丰宁| 百色市| 巴东县| 牡丹江市| 合肥市| 兴宁市| 察隅县| 轮台县| 章丘市| 浦县| 诏安县|