RESTful 與 webservice

接口抽象

RESTful Web 服務使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 來抽象全部 Web 系統的服務能力，而不一樣的是，SOAP 應用都經過定義本身個性化的接口方法來抽象 Web 服務，這更像咱們常常談到的 RPC。例如本例中的 getUserList 與 getUserByName 方法。

RESTful Web 服務使用標準的 HTTP 方法優點，從大的方面來說：標準化的 HTTP 操做方法，結合其餘的標準化技術，如 URI，HTML，XML 等，將會極大提升系統與系統之間整合的互操做能力。尤爲在 Web 應用領域，RESTful Web 服務所表達的這種抽象能力更加貼近 Web 自己的工做方式，也更加天然。

同時，使用標準 HTTP 方法實現的 RRESTful Web 服務也帶來了 HTTP 方法自己的一些優點：

• 無狀態性（Stateless）

HTTP 協議從本質上說是一種無狀態的協議，客戶端發出的 HTTP 請求之間能夠相互隔離，不存在相互的狀態依賴。基於 HTTP 的 ROA，以很是天然的方式來實現無狀態服務請求處理邏輯。對於分佈式的應用而言，任意給定的兩個服務請求 Request 1 與 Request 2, 因爲它們之間並無相互之間的狀態依賴，就不須要對它們進行相互協做處理，其結果是：Request 1 與 Request 2 能夠在任何的服務器上執行，這樣的應用很容易在服務器端支持負載平衡 (load-balance)。

• 安全操做與冪指相等特性（Safety /Idempotence）

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 複雜：

其1、全部通過緩存服務器的 SOAP 消息老是 HTTP POST，緩存服務器若是不解碼 SOAP 消息體，無法知道該 HTTP 請求是不是想從服務器得到數據。

其2、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, 瀏覽器幫你自動定向到你想訪問的頁面，並不依賴任何第三方的信息。

總結

典型的基於 SOAP 的 Web 服務以操做爲中心，每一個操做接受 XML 文檔做爲輸入，提供 XML 文檔做爲輸出。在本質上講，它們是 RPC 風格的。而在遵循 REST 原則的 ROA 應用中，服務是以資源爲中心的，對每一個資源的操做都是標準化的 HTTP 方法。

本文主要集中在以上的幾個方面，對 SOAP 與 REST 進行了對比，能夠看到，基於 REST 構建的系統其系統的擴展能力要強於 SOAP，這能夠體如今它的統一接口抽象、代理服務器支持、緩存服務器支持等諸多方面。而且，伴隨着 Web Site as Web Services 演進的趨勢，基於 REST 設計和實現的簡單性和強擴展性，有理由相信，REST 將會成爲 Web 服務的一個重要架構實踐領域。