REST & SOAP webservice 小結

REST：

　　 REST是一種架構設計，特色是面向資源，存在於互聯網的任何事物均可以理解爲資源，REST相比較SOAP WS具備比較低的開發門檻。

　　1. 網絡上的事物被抽象成資源，每一個資源對應惟一的資源標示（URI）

　　2. 全部對資源的操做都是無狀態的

　　REST遵循HTTP規範，其對資源的核心操做對應http method - get/post/put/delete(獲取、增長、修改、刪除)，經過URI來獲取資源並對其進行操做。

SOAP:

　　SOAP有嚴格的規範和標準，針對安全和事物等的管理更加成熟，同事強調操做方法和對象分離，有WSDL和XSD規範對其定義。對於複雜的業務活動邏輯，

　　將要操做的事物抽象成資源並非一件簡單的事，如事務處理，SOAP是更好的選擇。

 

SOAP Webservice和RESTful Webservice的比較（轉）

成熟度(總的來講SOAP在成熟度上優於REST)

SOAP雖然發展到如今已經脫離了初衷，可是對於異構環境服務發佈和調用，以及廠商的支持都已經達到了較爲成熟的狀況。不一樣平臺，開發語言之間經過SOAP來交互的web service都可以較好的互通（在部分複雜和特殊的參數和返回對象解析上，協議沒有做很細緻的規定，致使仍是須要做部分修正）

REST國外不少大網站都發布了本身的開發API，不少都提供了SOAP和REST兩種Web Service，根據調查部分網站的REST風格的使用狀況要高於SOAP。可是因爲REST只是一種基於Http協議實現資源操做的思想，所以各個網站的REST實現都自有一套，在後面會講訴各個大網站的REST API的風格。也正是由於這種各自實現的狀況，在性能和可用性上會大大高於SOAP發佈的web service，但統一通用方面遠遠不及SOAP。因爲這些大網站的SP每每專一於此網站的API開發，所以通用性要求不高。

因爲沒有相似於SOAP的權威性協議做爲規範，REST實現的各類協議僅僅只能算是私有協議，固然須要遵循REST的思想，可是這樣細節方面有太多沒有約束的地方。REST往後的發展所走向規範也會直接影響到這部分的設計是否可以有很好的生命力。

效率和易用性(REST更勝一籌)

SOAP協議對於消息體和消息頭都有定義，同時消息頭的可擴展性爲各類互聯網的標準提供了擴展的基礎，WS-*系列就是較爲成功的規範。可是也因爲SOAP因爲各類需求不斷擴充其自己協議的內容，致使在SOAP處理方面的性能有所降低。同時在易用性方面以及學習成本上也有所增長。

REST被人們的重視，其實很大一方面也是由於其高效以及簡潔易用的特性。這種高效一方面源於其面向資源接口設計以及操做抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。同時，在我看來REST還有一個很吸引開發者的就是可以很好的融合當前Web2.0的不少前端技術來提升開發效率。例如不少大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml做爲數據承載，還有（JSON,RSS,ATOM）等形式，這對不少網站前端開發人員來講就可以很好的mashup各類資源信息。

安全性：

這點其實能夠放入到成熟度中，不過在當前的互聯網應用和平臺開發設計過程當中，安全已經被提到了很高的高度，特別是做爲外部接口給第三方調用，安全性可能會高過業務邏輯自己。

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失去它高效性的優點越多。