SOAP和RESTful框架的簡介、對比和區別

幸運券發放發表於2018-02-12

SOAP和RESTful 框架的 簡介、對比和區別http://www.bieryun.com/1228.html

SOAP簡單物件訪問協議(Simple Object Access Protocol,SOAP)是一種基於 XML 的協議,可以和現存的許多因特網協議和格式結合使用,包括超文字傳輸協議(HTTP),簡單郵件傳輸協議(SMTP),多用途網際郵件擴充協議(MIME),基於“通用”傳輸協議是 SOAP的一個優點。它還支援從訊息系統到遠端過程呼叫(Remote Procedure Call,RPC)等大量的應用程式。SOAP提供了一系列的標準,如WSRM(WS-Reliable Messaging)形式化契約確保可靠性與安全性,確保非同步處理與呼叫;WS-Security、WS-Transactions和WS-Coordination等標準提供了上下文資訊與對話狀態管理。

相對而言,SOAP協議屬於複雜的、重量級的協議,當前隨著Web2.0的興起,表述性狀態轉移(Representational State Transfer,REST)逐步成為一個流行的架構風格。REST是一種輕量級的Web Service架構風格,其實現和操作比SOAP和XML-RPC更為簡潔,可以完全通過HTTP協議實現,還可以利用快取Cache來提高響應速度,效能、效率和易用性上都優於SOAP協議。REST架構對資源的操作包括獲取、建立、修改和刪除資源的操作正好對應HTTP協議提供的GET、POST、PUT和DELETE方法,這種針對網路應用的設計和開發方式,可以降低開發的複雜性,提高系統的可伸縮性。REST架構尤其適用於完全無狀態的CRUD(Create、Read、Update、Delete,建立、讀取、更新、刪除)操作。

基於REST的軟體體系結構風格(Software Architecture Style)稱之為面向資源體系架構(Resource-oriented Architecture,ROA)。按照REST原則設計的軟體、體系結構,通常被稱為“REST式的”(RESTful),在本文中以下稱之為RESTful Web服務,以便於和基於SOAP的Web服務區別。

伺服器端採用J2EE,客戶端採用JSP、Flex、JavaFX、AIR等可以直接呼叫Servlet,其他的實現技術基本上不能直接呼叫,但是無論是那種客戶端,對於基於SOAP的Web服務或者基於RESTful Web服務務都是支援的,如AJAX的 XMLHttpRequest、Flex的HTTPService等。如下圖所示:

客戶端和伺服器端的通訊方式

HTTP 的 GET、HEAD 請求本質上應該是安全的呼叫,即:GET、HEAD 呼叫不會有任何的副作用,不會造成伺服器端狀態的改變。對於伺服器來說,客戶端對某一 URI 做 n 次的 GET、HAED 呼叫,其狀態與沒有做呼叫是一樣的,不會發生任何的改變。

HTTP 的 PUT、DELTE 呼叫,具有冪指相等特性 , 即:客戶端對某一 URI 做 n 次的 PUT、DELTE 呼叫,其效果與做一次的呼叫是一樣的。HTTP 的 GET、HEAD 方法也具有冪指相等特性。

HTTP 這些標準方法在原則上保證你的分散式系統具有這些特性,以幫助構建更加健壯的分散式系統。

安全控制

為了說明問題,基於上面的線上使用者管理系統,我們給定以下場景:

參考一開始我們給出的用例圖,對於客戶端 Client2,我們只希望它能以只讀的方式訪問 User 和 User List 資源,而 Client1 具有訪問所有資源的所有許可權。

如何做這樣的安全控制?

通行的做法是:所有從客戶端 Client2 發出的 HTTP 請求都經過代理伺服器 (Proxy Server)。代理伺服器制定安全策略:所有經過該代理的訪問 User 和 User List 資源的請求只具有讀取許可權,即:允許 GET/HEAD 操作,而像具有寫許可權的 PUT/DELTE 是不被允許的。

如果對於 REST,我們看看這樣的安全策略是如何部署的。如下圖所示:

圖 4. REST 與代理伺服器 (Proxy Servers)
一般代理伺服器的實現根據 (URI, HTTP Method) 兩元組來決定 HTTP 請求的安全合法性。

當發現類似於(http://localhost:8182/v1/users/{username},DELETE)這樣的請求時,予以拒絕。

對於 SOAP,如果我們想借助於既有的代理伺服器進行安全控制,會比較尷尬,如下圖:

圖 5. SOAP 與代理伺服器 (Proxy Servers)

所有的 SOAP 訊息經過代理伺服器,只能看到(
http://localhost:8182/v1/soap/servlet/messagerouter
, HTTP POST)這樣的資訊,如果代理伺服器想知道當前的 HTTP 請求具體做的是什麼,必須對 SOAP 的訊息體解碼,這樣的話,意味著要求第三方的代理伺服器需要理解當前的 SOAP 訊息語義,而這種 SOAP 應用與代理伺服器之間的緊耦合關係是不合理的。

關於快取

眾所周知,對於基於網路的分散式應用,網路傳輸是一個影響應用效能的重要因素。如何使用快取來節省網路傳輸帶來的開銷,這是每一個構建分散式網路應用的開發人員必須考慮的問題。

HTTP 協議帶條件的 HTTP GET 請求 (Conditional GET) 被設計用來節省客戶端與伺服器之間網路傳輸帶來的開銷,這也給客戶端實現 Cache 機制 ( 包括在客戶端與伺服器之間的任何代理 ) 提供了可能。HTTP 協議通過 HTTP HEADER 域:If-Modified-Since/Last- Modified,If-None-Match/ETag 實現帶條件的 GET 請求。

REST 的應用可以充分地挖掘 HTTP 協議對快取支援的能力。當客戶端第一次傳送 HTTP GET 請求給伺服器獲得內容後,該內容可能被快取伺服器 (Cache Server) 快取。當下一次客戶端請求同樣的資源時,快取可以直接給出響應,而不需要請求遠端的伺服器獲得。而這一切對客戶端來說都是透明的。

圖 6. REST 與快取伺服器 (Cache Server)

而對於 SOAP,情況又是怎樣的呢?

使用 HTTP 協議的 SOAP,由於其設計原則上並不像 REST 那樣強調與 Web 的工作方式相一致,所以,基於 SOAP 應用很難充分發揮 HTTP 本身的快取能力,圖 7. SOAP 與快取伺服器 (Cache Server)

兩個因素決定了基於 SOAP 應用的快取機制要遠比 REST 複雜:

其一、所有經過快取伺服器的 SOAP 訊息總是 HTTP POST,快取伺服器如果不解碼 SOAP 訊息體,沒法知道該 HTTP 請求是否是想從伺服器獲得資料。

其二、SOAP 訊息所使用的 URI 總是指向 SOAP 的伺服器,如本文例子中的
http://localhost:8182/v1/soap/servlet/messagerouter
,這並沒有表達真實的資源 URI,其結果是快取伺服器根本不知道那個資源正在被請求,更不用談進行快取處理。

關於連線性

在一個純的 SOAP 應用中,URI 本質上除了用來指示 SOAP 伺服器外,本身沒有任何意義。與 REST 的不同的是,無法通過 URI 驅動 SOAP 方法呼叫。例如在我們的例子中,當我們通過

getUserList SOAP 訊息獲得所有的使用者列表後,仍然無法通過既有的資訊得到某個具體的使用者資訊。唯一的方法只有通過 WSDL 的指示,通過呼叫 getUserByName 獲得,getUserList 與 getUserByName 是彼此孤立的。

而對於 REST,情況是完全不同的:通過
http://localhost:8182/v1/users
URI 獲得使用者列表,然後再通過使用者列表中所提供的 LINK 屬性,例如
<link>http://localhost:8182/v1/users/tester</link>
獲得 tester 使用者的使用者資訊。這樣的工作方式,非常類似於你在瀏覽器的某個頁面上點選某個 hyperlink, 瀏覽器幫你自動定向到你想訪問的頁面,並不依賴任何第三方的資訊

REST 構建的系統其系統的擴充套件能力要強於 SOAP,這可以體現在它的統一介面抽象、代理伺服器支援、快取伺服器支援等諸多方面, 而SOAP的成熟性可以給需要提供給多開發語言的,多傳輸方式的,對於安全性要求較高的介面設計帶來便利。


相關文章