REST WebService與SOAP WebService的比較

在SOA的基礎技術實作方式中WebService占據了很重要的地位，通常我們提到WebService第一想法就是SOAP消息在各種傳輸協定上互動。近幾年REST的思想伴随着SOA逐漸被大家接受，同時各大網站不斷開放API提供給開發者，也激起了REST風格WebService的熱潮。

SOAP

       什麼是SOAP，我想不用多說，google一把滿眼都是。其實SOAP最早是針對RPC的一種解決方案，簡單對象通路協定，很輕量，同時作為應用協定可以基于多種傳輸協定來傳遞消息（Http,SMTP等）。但是随着SOAP作為WebService的廣泛應用，不斷地增加附加的内容，使得現在開發人員覺得SOAP很重，使用門檻很高。在SOAP後續的發展過程中，WS-*一系列協定的制定，增加了SOAP的成熟度，也給SOAP增加了負擔。

REST

       REST其實并不是什麼協定也不是什麼标準，而是将Http協定的設計初衷作了诠釋，在Http協定被廣泛利用的今天，越來越多的是将其作為傳輸協定，而非原先設計者所考慮的應用協定。SOAP類型的WebService就是最好的例子，SOAP消息完全就是将Http協定作為消息承載，以至于對于Http協定中的各種參數（例如編碼，錯誤碼等）都置之不顧。其實，最輕量級的應用協定就是Http協定。Http協定所抽象的get,post,put,delete就好比資料庫中最基本的增删改查，而網際網路上的各種資源就好比資料庫中的記錄（可能這麼比喻不是很好），對于各種資源的操作最後總是能抽象成為這四種基本操作，在定義了定位資源的規則以後，對于資源的操作通過标準的Http協定就可以實作，開發者也會受益于這種輕量級的協定。

    REST的思想歸結以下有如下幾個關鍵點：

1．面向資源的接口設計

所有的接口設計都是針對資源來設計的，也就很類似于我們的面向對象和面向過程的設計差別，隻不過現在将網絡上的操作實體都作為資源來看待，同時URI的設計也是展現了對于資源的定位設計。後面會提到有一些網站的API設計說是REST設計，其實是RPC-REST的混合體，并非是REST的思想。

       2．抽象操作為基礎的CRUD

       這點很簡單，Http中的get,put,post,delete分别對應了read,update,create,delete四種操作，如果僅僅是作為對于資源的操作，抽象成為這四種已經足夠了，但是對于現在的一些複雜的業務服務接口設計，可能這樣的抽象未必能夠滿足。其實這也在後面的幾個網站的API設計中暴露了這樣的問題，如果要完全按照REST的思想來設計，那麼适用的環境将會有限制，而非放之四海皆準的。      

       3．Http是應用協定而非傳輸協定

       這點在後面各大網站的API分析中有很明顯的展現，其實有些網站已經走到了SOAP的老路上，說是REST的理念設計，其實是作了一套私有的SOAP協定，是以稱之為REST風格的自定義SOAP協定。

4．無狀态，自包含

這點其實不僅僅是對于REST來說的，作為接口設計都需要能夠做到這點，也是作為可擴充和高效性的最基本的保證，就算是使用SOAP的WebService也是一樣。

REST vs SOAP

成熟度：

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日後的發展所走向規範也會直接影響到這部分的設計是否能夠有很好的生命力。

總的來說SOAP在成熟度上優于REST。

效率和易用性：

       SOAP協定對于消息體和消息頭都有定義，同時消息頭的可擴充性為各種網際網路的标準提供了擴充的基礎，WS-*系列就是較為成功的規範。但是也由于SOAP由于各種需求不斷擴充其本身協定的内容，導緻在SOAP處理方面的性能有所下降。同時在易用性方面以及學習成本上也有所增加。

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

       是以在效率和易用性上來說，REST更勝一籌。

安全性：

       這點其實可以放入到成熟度中，不過在目前的網際網路應用和平台開發設計過程中，安全已經被提到了很高的高度，特别是作為外部接口給第三方調用，安全性可能會高過業務邏輯本身。

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

應用設計與改造：

       我們的系統要麼就是已經有了那些需要被釋出出去的服務，要麼就是剛剛設計好的服務，但是開發人員的傳統設計思想讓REST的形式被接受還需要一點時間。同時在資源型資料服務接口設計上來說按照REST的思想來設計相對來說要容易一些，而對于一些複雜的服務接口來說，可能強要去按照REST的風格來設計會有些牽強。這一點其實可以看看各大網站的接口就可以知道，很多網站還要傳入function的名稱作為參數，這就明顯已經違背了REST本身的設計思路。

       而SOAP本身就是面向RPC來設計的，開發人員十分容易接受，是以不存在什麼适應的過程。

總的來說，其實還是一個老觀念，适合的才是最好的

       技術沒有好壞，隻有是不是合适，一種好的技術和思想被誤用了，那麼就會得到反效果。REST和SOAP各自都有自己的優點，同時如果在一些場景下如果去改造REST，其實就會走向SOAP（例如安全）。