一、Soap和Rest的定義
SOAP（Simple Object Access Protocol 簡單對象訪問協議），用於在Web Service中把遠程調用和返回封裝成機器可讀的格式化數據，事實上SOAP使用XML數據格式，以描述調用的遠程過程、參數、返回值和出錯信息等等。其實SOAP最早是針對RPC的一種解決方案，很輕量，同時作為應用協議可以基於多種傳輸協議來傳遞消息（Http,SMTP等）。但是隨着SOAP作為WebService的廣泛應用，不斷地增加附加的內容，使得現在開發人員覺得SOAP很重，使用門檻很高，而且隨着需求的增長，又不得增加協議以支持安全性，這使SOAP變得異常龐大，背離了簡單的初衷。在SOAP后續的發展過程中，WS-*一系列協議的制定，增加了SOAP的成熟度，也給SOAP增加了負擔。SOAP 常常被稱作“web services”，這是一個誤稱。SOAP 和 web 基本上說不上話。REST 提供的才是真正的基於URL 和 HTTP 的 “web services”。
REST(Representational State Transfort表述性狀態傳遞)形式上應該表述為客戶端通過申請資源來實現狀態的轉換，在這個角度系統可以看成一台虛擬的狀態機。按照REST原則設計的軟件、體系結構，通常被稱為“REST式的”（RESTful），拋開R. T. Fielding博士論文里晦澀的理論不說，REST應該滿足這樣的特點：
1)客戶端和服務器結構；
2)連接協議具有無狀態性；
3)能夠利用Cache機制增進性能；
4)層次化的系統；
5)按需代碼。
REST只是一種架構風格，而不是協議或標准。但這種新的風格對現有的以SOAP為代表的Web Service造成的沖擊也是革命性的，因為它面向資源，甚至連服務也抽象成資源，因為它和HTTP緊密結合，且服務器無狀態。服務器端采用J2EE，客戶端采用JSP、Flex、JavaFX、AIR等可以直接調用Servlet，其他的實現技術基本上不能直接調用，但是無論是那種客戶端，對於基於SOAP的Web服務或者基於RESTful Web服務務都是支持的，如AJAX的 XMLHttpRequest、Flex的HTTPService等。
二、Soap VS Rest
①在成熟度上
soap對於異構環境服務發布與調用，以及廠商的支持都達到了一定的成熟度，不同平台，開發語言通過soap來交互web service都能較好的互通；
rest是一種基於http協議實現資源操作的思想，但是沒有類似於soap的權威性協議作為規范，rest實現的各種協議只能算是遵循rest思想的私有協議，所以在細節方面沒有太多的約束。
soap在成熟度上優於rest。
②效率和易用性
soap協議對於消息體和消息頭都有定義，同時消息頭的可擴展性為各種互聯網的標准提供了擴展的基礎，WS_*系列就是較為成功的規范。但是soap由於各種需求不斷擴充其本身協議的內容，導致soap在處理方面的性能有所下降，同時在易用性和學習方面的成本有所提升；
rest被人們所重視，很大一方面是因為其高效以及簡潔易用的特性，這種高效一方面源於其面向資源接口設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了http最初的應用協議設計理念，同時，rest還有一個很吸引開發者的就是能夠很好地融合當前web2.0的很多前端技術來提高效率，例如很多大型網站開放的rest風格的API都會有很多種返回形式，除了傳統的XML作為承載，還有json、rss、atom等形式，這對很多前端開發人員來說就能夠很好的mashup各種資源信息。
在效率和易用性上，rest更勝一籌。
③在應用設計和改造上
rest對於資源服務型接口來說很合適，同時特別適合對於效率要求很高，但是對於安全不高的場景，而soap的成熟性可以給安全要求性和高的接口設計帶來便利，所以我覺得純粹說什么設計模式將會占據主導地位沒有什么意義，關鍵還是要適合應用場景。
三、Why Rest？
- REST 使用了標准 HTTP 因此它做什么都更加簡單。創建客戶端，開發 API，文檔更易於理解，而且沒有一件事用 REST 做起來不比 SOAP 更簡單/更好。
- REST 允許很多不同的數據格式而 SOAP 僅支持 XML。雖然這樣看起來給 REST 增加了復雜度因為你需要處理多種格式，但以我的經驗來看這樣實際上有很多好處。JSON 通常更適用於承載數據而且解析起來更快。由於其對 JSON 的支持，REST 允許我們更好地支持瀏覽器客戶端。
- REST 具備更好的性能和可擴展性。REST 讀取可以被緩存起來，而基於 SOAP 的讀取無法被緩存。
舉一個圖書館在線查詢管理系統為例，服務提供者必須為每一本書提供一個內部標識，然后可能定義一個listBooks操作來返回一系列圖書，一個getBook操作來返回指定的圖書，一個createBook操作來向數據庫加入新增的圖書，一個deleteBook操作來刪除作廢的圖書，每個操作都有各自的參數，尤其是用內部標識來標識操作的圖書。這種設計被詬病之處，在於deleteBook操作也要用POST方法來發送，而其實HTTP協議有更和邏輯的DELETE方法可用。REST正是這樣設計的，REST為每一個資源（此處是圖書）指定一個唯一的URI，而用HTTP的4種方法GET、POST、PUT、DELETE直觀地表示獲取、創建、更新和刪除圖書。同時圖書集合也是和單本的圖書不同的資源，如果用/books來代表圖書列表，/books/ID來代表標識為ID的圖書，那么對/books的GET操作就代表返回整個圖書列表，對/books/ID的DELETE操作代表刪除指定的圖書，等等。
四、Why Soap？
①web services 安全
SOAP 不僅像 REST 一樣支持 SSL，而且還支持增加了很多企業級安全特性的 WS-Security(WS = web services)。因此它能夠提供通過中介的身份驗證，而不僅僅是端對端的驗證(SSL)。此外，SOAP 還提供了一個數據完整性和數據隱私性的標准實現。叫它“企業級”並不是說它更安全，它只是簡單提供了典型互聯網服務不需要的幾個安全工具而已，事實上這些工具只有在很少的一些“企業級”場景下才能派的上用場。
②web services 原子性事務
如果服務需要 ACID 事務的話，那么你就需要 SOAP 了。盡管 REST 也支持事務，但它並非完整性的而且不具備 ACID。幸運的是 ACID 事務對於互聯網來說幾乎沒有任何意義。REST 受限於 HTTP，HTTP 本身無法提供兩階段提交分布式事務資源，但是 SOAP 可以。互聯網應用一般不會需要這等級別的事務可靠性，企業級應用有時會需要。（ACID，指數據庫事務正確執行的四個基本要素的縮寫。包含：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability））
③web services 消息可靠性
REST 不具備一個標准的消息體系，它期望客戶端通過重試來處理通信失敗。SOAP 具備內置的成功/重試邏輯並通過 SOAP 中介來提供端對端的可靠性。
例如，如果我去寫一個連接到我的銀行的 iPhone 應用那么我當然需要使用 SOAP。上述三點特性都是銀行事務所必須的。比如，如果我將資金從一個賬戶轉移到另外一個賬戶，我需要確定它的完成。如果第一次轉賬成功，但響應失敗，這個時候的 REST 重試將會是災難性的。
個人理解，在SoapUI工具中，如果發現接口是xml進行響應傳輸數據，就使用New SOAP Project；其它一律使用New REST Project，比如接口返回是JSON格式的。
參考資料：https://www.soapui.org/learn/tutorials/web-service-example-projects.html