1、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等標準提供了上下文信息與對話狀態管理。
2、RESTful簡述
一種軟件架構風格，設計風格而不是標準，只是提供了一組設計原則和約束條件。它主要用於客戶端和服務器交互類的軟件。基於這個風格設計的軟件可以更簡潔，更有層次，更易於實現緩存等機制。
REST（英文：Representational State Transfer，簡稱REST）描述了一個架構樣式的網絡系統，比如 web 應用程序。它首次出現在 2000年Roy Fielding的博士論文中，他是HTTP規範的主要編寫者之一。在目前主流的三種Web服務交互方案中，REST相比於SOAP（Simple Object Access protocol，簡單對象訪問協議）以及XML-RPC更加簡單明瞭，無論是對URL的處理還是對Payload的編碼，REST都傾向於用更加簡單輕量的方法設計和實現。值得注意的是REST並沒有一個明確的標準，而更像是一種設計的風格。
3、SOAP與RESTful區別
Web服務有兩種實現方式，一是SOAP協議方式，二是REST方式。SOAP是一套完整的實現Web服務的解決方案。這裏有必要先簡單瞭解SOAP方式的Web服務，然後對比SOAP方式，我們會發現REST方式欠缺了什麼。
SOAP方式的Web服務中的Web服務描述語言（WSDL）和簡單對象訪問協議（SOAP）一起構成了SOAP方式下的Web服務的結構單元。客戶端通過WSDL可以瞭解Web服務公開了那些可以被執行的方法以及Web服務可以發送或接收的消息格式（解決了公佈訪問資源方法的問題）。客戶端按照SOAP將調用位於遠程系統上的服務所需信息序列化爲消息（解決了如何調用遠程方法的問題）。注意WSDL描述的服務以及SOAP消息都是符合統一標準的，都是機器可讀的.
WSDL基於XML格式，用來描述Web服務。WSDL文檔可以看成是客戶端和服務器之間的一個協約。使用WSDL工具，你可以自動處理這個過程，幾乎不用手工編寫代碼就能夠讓應用程序整合新的服務。因此WSDL是Web服務體系結構的基礎，因爲它提供了一個通用語言，用來描述服務和整合這些服務的平臺。
SOAP本身提供了與Web服務交換信息的方法。SOAP是序列化調用位於遠程系統上的服務所需信息的標準方法，這些信息可以使用一種遠程系統能夠讀懂的格式通過網絡發送到遠程系統，而不必關心遠程系統運行於何種平臺或者使用何種語言編寫。SOAP以XML格式提供了一個簡單、輕量的用於在分散或分佈環境中交換結構化和類型信息的機制。實際上它通過提供一個有標準組件的包模型和在模塊中編碼數據的機制，定義了一個簡單的表示應用程序語義的機制。
對照SOAP方式的Web服務，REST中沒有用於描述資源（服務）列表，資源元數據的類似於WSDL的東東。所以有人在2009年提出了一個標準WADL去描述REST方式的Web服務，但至今沒有被標準化。個人認爲使用WSDL/WADL去描述REST方式的Web服務太彆扭，這是典型的RPC思路，而REST是一種把服務抽象爲資源的架構思想。用描述RPC的WSDL去描述REST方式的Web服務並不合適。我們需要其他策略去代替WSDL實現“公佈訪問資源方法的問題”。
4、SOAP與RESTful對比
1）、成熟度：
SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務發佈和調用，以及廠商的支持都已經達到了較爲成熟的情況。不同平臺，開發語言之間通過SOAP來交互的web service都能夠較好的互通（在部分複雜和特殊的參數和返回對象解析上，協議沒有作很細緻的規定，導致還是需要作部分修正）
REST國外很多大網站都發布了自己的開發API，很多都提供了SOAP和REST兩種Web Service，根據調查部分網站的REST風格的使用情況要高於SOAP。但是由於REST只是一種基於Http協議實現資源操作的思想，因此各個網站的REST實現都自有一套，在後面會講訴各個大網站的REST API的風格。也正是因爲這種各自實現的情況，在性能和可用性上會大大高於SOAP發佈的web service，但統一通用方面遠遠不及SOAP。由於這些大網站的SP往往專注於此網站的API開發，因此通用性要求不高。
ASF上考慮發佈REST風格的Web Service，可以參考幾大網站的設計（兄弟公司的方案就是參考了類似於flickr的設計模式），但是由於沒有類似於SOAP的權威性協議作爲規範，REST實現的各種協議僅僅只能算是私有協議，當然需要遵循REST的思想，但是這樣細節方面有太多沒有約束的地方。REST日後的發展所走向規範也會直接影響到這部分的設計是否能夠有很好的生命力。
總的來說SOAP在成熟度上優於REST。
2）、效率和易用性：
SOAP協議對於消息體和消息頭都有定義，同時消息頭的可擴展性爲各種互聯網的標準提供了擴展的基礎，WS-*系列就是較爲成功的規範。但是也由於SOAP由於各種需求不斷擴充其本身協議的內容，導致在SOAP處理方面的性能有所下降。同時在易用性方面以及學習成本上也有所增加。
REST被人們的重視，其實很大一方面也是因爲其高效以及簡潔易用的特性。這種高效一方面源於其面向資源接口設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。同時，在我看來REST還有一個很吸引開發者的就是能夠很好的融合當前Web2.0的很多前端技術來提高開發效率。例如很多大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml作爲數據承載，還有（JSON,RSS,ATOM）等形式，這對很多網站前端開發人員來說就能夠很好的mashup各種資源信息。
因此在效率和易用性上來說，REST更勝一籌。
3）、安全性：
這點其實可以放入到成熟度中，不過在當前的互聯網應用和平臺開發設計過程中，安全已經被提到了很高的高度，特別是作爲外部接口給第三方調用，安全性可能會高過業務邏輯本身。
SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實現安全控制的，當前已經得到了各個廠商的支持，.net ，php ，java 都已經對其有了很好的支持（雖然在一些細節上還是有不兼容的問題，但是互通基本上是可以的）。
REST沒有任何規範對於安全方面作說明，同時現在開放REST風格API的網站主要分成兩種，一種是自定義了安全信息封裝在消息中（其實這和SOAP沒有什麼區別），另外一種就是靠硬件SSL來保障,但是這隻能夠保證點到點的安全，如果是需要多點傳輸的話SSL就無能爲力了。安全這塊其實也是一個很大的問題，今年在BEA峯會上看到有演示採用SAML2實現的網站間SSO，其實是直接採用了XML-Security和XML-Signature，效率看起來也不是很高。未來REST規範化和通用化過程中的安全是否也會採用這兩種規範，是未知的，但是加入的越多，REST失去它高效性的優勢越多。
4）、應用設計與改造：
我們的系統要麼就是已經有了那些需要被髮布出去的服務，要麼就是剛剛設計好的服務，但是開發人員的傳統設計思想讓REST的形式被接受還需要一點時間。同時在資源型數據服務接口設計上來說按照REST的思想來設計相對來說要容易一些，而對於一些複雜的服務接口來說，可能強要去按照REST的風格來設計會有些牽強。這一點其實可以看看各大網站的接口就可以知道，很多網站還要傳入function的名稱作爲參數，這就明顯已經違背了REST本身的設計思路。
而SOAP本身就是面向RPC來設計的，開發人員十分容易接受，所以不存在什麼適應的過程。
總結：總體來說各有優勢，技術不分輸贏，都有自己的優劣，主要還是看業務的需要來衡量使用哪種技術。
參考地址
1、 https://blog.csdn.net/wdeng2011/article/details/78274683
2、 https://www.cnblogs.com/wjwen/p/6549024.html
3、 https://www.cnblogs.com/klb561/p/9929875.html