跳轉到內容

我夢寐以求的物聯網/第 3 章:物聯網與 Web 服務

來自華夏公益教科書,開放的書籍,開放的世界

Web 服務簡介

[編輯 | 編輯原始碼]

Web 服務是高度可用的分散式應用程式元件。我們可以使用它們來整合用不同語言編寫並在不同平臺上執行的計算機應用程式。HTTP 等 Web 服務是語言和平臺無關的,因為供應商已就通用 Web 服務標準達成一致。HTTP Web 服務使用 HTTP 的操作與遠端伺服器交換資料。如果您想從伺服器獲取資料,請使用 HTTP GET,將新資料傳送到伺服器,並使用 HTTP POST 和其他一些函式。就是這樣:沒有登錄檔、沒有信封、沒有包裝器和沒有隧道。HTTP 協議中內建的“動詞”直接對映到應用程式級操作,用於檢索、建立資料等。

如何訪問 Web 服務

[編輯 | 編輯原始碼]

SOAP 代表簡單物件訪問協議,是一種基於標準的 Web 服務訪問協議。SOAP 提供長期效益,並且已經存在了一段時間。SOAP 由微軟開發,使用 XML 提供訊息服務,儘管在 SOAP 中發出請求和接收響應可能變得極其複雜。與其他程式語言一樣,SOAP 的 XML 對錯誤不寬容。但是,SOAP 最重要的功能之一是其內建的錯誤處理;如果請求出現問題,系統會發送包含錯誤資訊的響應。[1]

REST 代表具象狀態傳輸,它包含一組無狀態的架構原則。REST 可以管理專注於系統資源以及如何在 HTTP 上透過各種用不同語言編寫的客戶端來定址和傳輸資源狀態的 Web 服務。REST 充當輕量級替代方案,在許多情況下使用簡單的 URL 而不是 XML 來進行請求。REST 允許許多不同的資料格式,從表面上看增加了複雜性。但是,由於支援 JSON,這使得 REST 能夠更好地支援瀏覽器客戶端,因為 JSON 通常更適合資料並且解析速度更快。[1][2]

SOAP:[1]

  • 是語言、平臺和傳輸無關的
  • 在分散式企業環境中證明效率很高
  • 是標準化的
  • 以 WS* 標準的形式提供顯著的預構建可擴充套件性
  • 提供內建錯誤處理
  • 允許自動化任務

REST:[1][2]

  • 使用更小的訊息格式
  • 執行速度快,因為不需要大量處理
  • 在設計理念上類似於其他 Web 技術
  • 證明與 Web 服務互動的成本低
  • 提供更小的學習曲線

哪一個更適合物聯網?

SOAP 和 REST 都適合物聯網 (IoT)。REST 更適合涉及移動裝置和嵌入式裝置的物聯網應用程式,而 SOAP 更符合業務應用程式的要求。這是因為 REST 代表了實現智慧事物全球網路的最直接、最簡單的方式,而 SOAP 具有強大的安全要求。[3]

HTTP 協議

[編輯 | 編輯原始碼]

現有的 HTTP/1.1

[編輯 | 編輯原始碼]

HTTP/1.1 透過提供持久連線來加速資訊流,持久連線允許將多個請求批處理或流水線到輸出緩衝區。當支援 HTTP/1.1 的瀏覽器指示它可以解壓縮 HTML 檔案時,伺服器將壓縮它們以透過網際網路傳輸,從而在必須傳輸的資料量方面節省大量的聚合。除此之外,HTTP/1.1 還提供允許多個域名共享同一個網際網路地址 (IP 地址) 的功能。這簡化了託管多個網站的 Web 伺服器的處理,這種做法有時被稱為虛擬主機。[4]

HTTP/2,下一代

[編輯 | 編輯原始碼]

HTTP/2 中出現的主要改進是:[5]

  1. 單個 HTTP 連線中的多個流(多路複用):流類似於資料通道。從客戶端到伺服器的單個已建立資料連線在其內部有多個流。這意味著各種流可以在同一連線單元中在伺服器和客戶端之間交換資料。無論是客戶端還是伺服器,或者共享流,雙方都可以同時交換資料,並且流可以由客戶端或伺服器斷開或關閉。
  2. 在請求中設定優先順序:客戶端請求的具有額外緊急性的資料可以設定優先順序標誌,接收端會處理該標誌。流識別符號用於宣告流的優先順序,它也是藉助 31 位優先順序識別符號設定的。值 0 表示高優先順序流。

HTTP 演進

[編輯 | 編輯原始碼]

HTTP/1:快速增長和資訊 RFC

從 1991 年到 1995 年,HTML 規範發生了快速協同演進,而網頁瀏覽器也作為一種新型軟體,在面向消費者的公共網際網路基礎設施快速發展的推動下,迅速崛起。不斷增長的公共網路對新興網路期望的功能和用例的需求,很快暴露出 HTTP/0.9 的許多基本侷限性。需要一種新的協議,不僅能夠提供超文字文件,還需要支援關於請求和響應的更豐富的元資料,並能夠實現內容協商等功能。作為回應,新興的網頁開發人員社群透過一種臨時性的過程,建立了大量的實驗性 HTTP 伺服器和客戶端實現,這些實現可以被其他人實施、部署和可能採用。[6]

HTTP/1.1:網際網路標準

HTTP/1.1 標準解決了早期版本中發現的許多協議歧義,並引入了一些關鍵的效能最佳化。最明顯的區別是:它允許對兩個物件進行請求,一個是 HTML 頁面,一個是影像,這兩個請求都透過單個連線傳遞。這個連線可以保持活動狀態,允許重複使用現有的 TCP 連線進行對同一主機的多個請求,從而提供更快的終端使用者體驗。為了終止持久連線,第二個客戶端請求可以透過連線頭向伺服器傳送一個明確的關閉令牌。類似地,伺服器可以在響應傳輸完成後,通知客戶端關閉當前 TCP 連線的意圖。從技術上講,任何一方都可以在任何時候終止 TCP 連線而無需發出此類訊號,但客戶端和伺服器應儘可能提供此訊號,以便在雙方實現更好的連線重用策略。 [4][6]

HTTP/2:改進傳輸效能

為了克服新的挑戰,HTTP 協議不得不進行演變。2012 年,HTTP 工作組宣佈開始開發新的 HTTP/2.0 協議,規範於 2015 年 5 月釋出。HTTP/2 的主要目標是提高傳輸效能,實現更低的延遲和更高的吞吐量。重要的是要記住,所有高階協議語義都沒有受到影響,這意味著所有 HTTP 標頭、值和用例都是相同的。任何現有的網站或應用程式都可以在不修改的情況下透過 HTTP/2 傳輸。HTTP 伺服器必須支援 HTTP/2,但這對於大多數使用者來說應該是透明的升級。如果工作組能夠實現其目標,唯一的區別應該是我們的應用程式將以更低的延遲和更好的網路鏈路利用率交付。[5][6]

HTML5 for IoT

[edit | edit source]

HTML 4.x 概述

[edit | edit source]

HTML 4.x 是第一個將層疊樣式表作為 HTML 標準一部分的版本。為了實現過渡,W3C 提供了三個版本的 HTML 4:過渡版、框架集版和嚴格版。雖然它繼續作為許多 HTML 核心特性的粗略指南,但它沒有提供足夠的資訊來構建相互之間以及更重要的是與網路內容互操作的實現。此外,HTML 4 透過樣式表、指令碼、框架和嵌入物件機制擴充套件了 HTML,並改進了對從右到左和混合方向文字、豐富表格和表單的支援,同時還為殘疾人提供了更好的可訪問性。[7][8]

使用 WebSocket 的 HTML5 用於 IoT

[edit | edit source]

WebSocket 提供了一種新的客戶端和伺服器之間的協議,它執行在持久 TCP 連線之上。雙向和全雙工訊息可以透過單個 TCP 套接字連線(同時或來回)透過 TCP 連線傳送。這是因為它是一個獨立的基於 TCP 的協議,理想情況下不需要 HTTP 隧道,從而簡化了傳送訊息時的通訊。[9]

使用 WebSocket 的 HTML5 是否更適合 IoT?它傾向於更適合,因為 WebSocket 更適合涉及低延遲通訊的情況,特別是對於客戶端到伺服器的訊息。對於伺服器到客戶端的資料,您可以使用長時間保持的連線和分塊傳輸來獲得相當低的延遲。但是,這無助於解決客戶端到伺服器的延遲,這需要為每個客戶端到伺服器的訊息建立新的連線。[9]

語義 Web 服務

[edit | edit source]

語義 Web 服務與其他傳統 Web 服務一樣,位於客戶端-伺服器系統的伺服器端,用於透過全球資訊網進行機器與機器的互動。在 2001 年 5 月的《科學美國人》雜誌上,伯納斯-李等人描述了它:“語義 Web 是當前 Web 的擴充套件,其中資訊被賦予明確的含義,從而使計算機和人能夠更好地協同工作。”[10]它是當前 Web 的高階形式,其中所有內容都具有明確的含義(易於資訊解釋),並且它使機器能夠自動處理 Web 內容(機器可訪問)。在語義 Web 服務組合中,機器可以根據使用者約束自動選擇、整合和呼叫各種 Web 服務,以實現使用者指定的任務。Web 執行比使用者更多的工作,因為它涉及在沒有使用者參與的情況下在 Web 上執行的例行和複雜任務,從而節省了組合和整合資訊的時間。機器可處理的語義被新增到資料中,在明確定義的語義的幫助下,機器可以理解資訊並代表人類使用者處理資訊,而 Web 服務則旨在為分散式計算提供全球基礎設施。 [10]

本體 Web 語言 (OWL)

[edit | edit source]

OWL 是一種高階語言(基於 XML),用於描述 Web 服務的屬性。它由三個部分組成:服務配置檔案、過程模型和基礎。服務配置檔案包括一般資訊,用於描述服務將要做什麼。過程模型描述了服務將如何執行其功能,而基礎描述了與行業標準的連結。它的主要目標是使使用者能夠在特定條件下自動發現、呼叫、組合和執行 Web 服務。 [11]

Web 服務建模本體 (WSMO)

[edit | edit source]

WSMO 用於描述 Web 服務的語義。它由四個部分組成:目標、本體、中介和 Web 服務。目標定義了使用者的願望。本體為描述資料的術語定義了正式語義,以實現與其他 WSMO 元素的互操作性。中介用於處理不同 WSMO 元素之間的互操作性問題,而 Web 服務則描述了現有已部署服務的函式行為、前提條件、後置條件、控制流等。 [12]

Web 服務是所謂的可程式設計 Web 的關鍵元素之一。它們可以有效地用於參與和建立企業對企業的交易,並且非常擅長向用戶公開軟體功能,同時整合異構平臺。Web 服務基於開放且普遍接受的網際網路協議。它們並非萬能,但無疑代表了我們都在尋找的一類軟體代理。

參考文獻

[編輯 | 編輯原始碼]
  1. a b c d Mueller, J. (2013 年 1 月 8 日). "理解 SOAP 和 REST 基礎以及差異". SmartBear 部落格. SmartBear 軟體公司. 檢索於 2016 年 5 月 19 日.
  2. a b Rodriguez, A. (2015 年 2 月 9 日). "RESTful Web 服務:基礎". IBMdeveloperWorks. IBM. 檢索於 2016 年 5 月 19 日.
  3. Guinard, D.; Ion, I.; Mayer, S. (2012). "尋找物聯網服務架構:REST 還是 WS-*?開發人員視角". 在 Puiatti, A.; Gu, T. (編). 移動與泛在系統:計算、網路與服務. 施普林格柏林海德堡. pp. 326–337. doi:10.1007/978-3-642-30973-1_32. ISBN 978-3-642-30973-1.{{cite book}}: CS1 maint: multiple names: authors list (link)
  4. a b "HTTP 1.1 定義". SearchSOA. TechTarget. 2005 年 9 月. 存檔於 原文 2015 年 10 月 27 日. 檢索於 2016 年 5 月 19 日.
  5. a b Pillai, S. (2013 年 7 月 31 日). "HTTP 版本 2 協議中的最新改進". /ROOT.IN. 檢索於 2016 年 5 月 19 日.
  6. a b c Grigorik, I. (2013). "第 9 章:HTTP 簡史". 高效能瀏覽器網路. O'Reilly 媒體公司. ISBN 9781449344764. 檢索於 2016 年 5 月 19 日.
  7. Williams, N. (2004). "HTML4 是關於什麼的?". CodeHelp.co.uk. 檢索於 2016 年 5 月 19 日.
  8. "HTML 4 簡介". HTML 4.01 規範. 全球資訊網聯盟. 1999 年 12 月 24 日. 檢索於 2016 年 5 月 19 日.
  9. a b 4esn0k (2013 年 2 月 5 日). "WebSocket 協議與 HTTP". Stack Overflow. Stack Exchange, Inc. 檢索於 2016 年 5 月 19 日.
  10. a b Marchiori, M.; Epifani, A.; Trevisan, S. "語義網簡明教程". Metalog - 邁向語義網. 全球資訊網聯盟. 檢索於 2016 年 5 月 19 日.{{cite web}}: CS1 maint: multiple names: authors list (link)
  11. Martin, D.; Burstein, M.; Hobbs, J. 等. (2004 年 11 月 22 日). "OWL-S:Web 服務的語義標記". 全球資訊網聯盟. 檢索於 2016 年 5 月 19 日. {{cite web}}: 明確使用等等:|author= (幫助)CS1 maint: multiple names: authors list (link)
  12. Roman, D.; Lausen, H.; Keller, U. 等 (2005 年 2 月 10 日). "D2v1.1. Web Service Modeling Ontology (WSMO)". WSMO 工作組. 檢索於 2016 年 5 月 19 日. {{cite web}}: 在“作者”引數中顯式使用“et al.”: |author= (幫助)CS1 維護:多個名稱:作者列表 (連結)
華夏公益教科書