知識星球（點選上方公眾號，可快速關註）
來源：luckykapok918，
luckykapok918.blog.163.com/blog/static/20586504320123238260833/
簡單物件訪問協議（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，我們看看這樣的安全策略是如何部署的。如下圖所示：
一般代理伺服器的實現根據 (URI, HTTP Method) 兩元組來決定 HTTP 請求的安全合法性。
當發現類似於（http://localhost:8182/v1/users/{username}，DELETE）這樣的請求時，予以拒絕。
對於 SOAP，如果我們想借助於既有的代理伺服器進行安全控制，會比較尷尬，如下圖：
所有的 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) 快取。當下一次客戶端請求同樣的資源時，快取可以直接給出響應，而不需要請求遠端的伺服器獲得。而這一切對客戶端來說都是透明的。
而對於 SOAP，情況又是怎樣的呢？
使用 HTTP 協議的 SOAP，由於其設計原則上並不像 REST 那樣強調與 Web 的工作方式相一致，所以，基於 SOAP 應用很難充分發揮 HTTP 本身的快取能力。
兩個因素決定了基於 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 屬性，例如
http://localhost:8182/v1/users/tester
獲得 tester 使用者的使用者資訊。這樣的工作方式，非常類似於你在瀏覽器的某個頁面上點選某個 hyperlink, 瀏覽器幫你自動定向到你想訪問的頁面，並不依賴任何第三方的資訊
REST 構建的系統其系統的擴充套件能力要強於 SOAP，這可以體現在它的統一介面抽象、代理伺服器支援、快取伺服器支援等諸多方面, 而SOAP的成熟性可以給需要提供給多開發語言的，多傳輸方式的，對於安全性要求較高的介面設計帶來便利。
看完本文有收穫？請轉發分享給更多人
關註「ImportNew」，提升Java技能
