淺談SOAP Webservice和RESTful Webservice

      REST是一種架構風格，其核心是面向資源，REST專門針對網絡應用設計和開發方式，以降低開發的復雜性，提高系統的可伸縮性。REST提出設計概念和準則為：

      1.網絡上的所有事物都可以被抽象為資源(resource)

      2.每一個資源都有唯一的資源標識(resource identifier)，對資源的操作不會改變這些標識

      3.所有的操作都是無狀態的

      REST簡化開發，其架構遵循CRUD原則，該原則告訴我們對於資源(包括網絡資源)只需要四種行為：創建，獲取，更新和刪除就可以完成相關的操作和處理。您可以通過統一資源標識符（Universal Resource Identifier，URI）來識別和定位資源，並且針對這些資源而執行的操作是通過 HTTP 規範定義的。其核心操作只有GET,PUT,POST,DELETE。

      由於REST強制所有的操作都必須是stateless的，這就沒有上下文的約束，如果做分布式，集群都不需要考慮上下文和會話保持的問題。極大的提高系統的可伸縮性。

      對於SOAP Webservice和Restful Webservice的選擇問題，首先需要理解就是SOAP偏向於面向活動，有嚴格的規範和標準，包括安全，事務等各個方面的內容，同時SOAP強調操作方法和操作對象的分離，有WSDL文件規範和XSD文件分別對其定義。而REST強調面向資源，只要我們要操作的對象可以抽象為資源即可以使用REST架構風格。

      如果從這個意義上講，是否使用REST就需要考慮資源本身的抽象和識別是否困難，如果本身就是簡單的類似增刪改查的業務操作，那麽抽象資源就比較容易，而對於復雜的業務活動抽象資源並不是一個簡單的事情。比如校驗用戶等級，轉賬，事務處理等，這些往往並不容易簡單抽象為資源。

      其次如果有嚴格的規範和標準定義要求，而且前期規範標準需要指導多個業務系統集成和開發的時候，SOAP風格由於有清晰的規範標準定義是明顯有優勢的。我們可以在開始和實現之前就嚴格定義相關的接口方法和接口傳輸數據。

      簡單數據操作，無事務處理，開發和調用簡單這些是使用REST架構風格的優勢。而對於較為復雜的面向活動的服務，如果我們還是使用REST，很多時候都是仍然是傳統的面向活動的思想通過轉換工具再轉換得到REST服務，這種使用方式是沒有意義的。

      REST核心是url和面向資源，url代替了原來復雜的操作方法。REST允許我們通過url設計系統，就像測試驅動開發使用測試用例設計類接口一樣。所有可以被抽象為資源的東西都可以使用RESTful的url，當我們以傳統的用SOAP方式實現的一個查詢訂單服務的時候可以看到，這個服務首先存在輸入的查詢條件，然後才是輸出結果集。那麽對於類似場景要使用REST，不可避免的會將傳統的SOAP服務拆分為一個HTTP POST操作和一個HTTP GET操作。前面是輸入，而後面是輸出。

      使用REST的關鍵是如何抽象資源，抽象的越精確，對REST的應用越好。如何進行抽象，面向資源的設計和傳統的面向結構和對象設計區別，資源和對象，數據庫表之間的差別是另外一個在分析設計時候要考慮的問題。在REST分析設計中如何改變傳統的SOAP分析設計思想又是一個重要問題。

      在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也是一樣。

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

應用設計與改造

      我們的系統要麽就是已經有了那些需要被發布出去的服務，要麽就是剛剛設計好的服務，但是開發人員的傳統設計思想讓REST的形式被接受還需要一點時間。同時在資源型數據服務接口設計上來說按照REST的思想來設計相對來說要容易一些，而對於一些復雜的服務接口來說，可能勉強要去按照REST的風格來設計會有些牽強。這一點其實可以看看各大網站的接口就可以知道，很多網站還要傳入function的名稱作為參數，這就明顯已經違背了REST本身的設計思路。而SOAP本身就是面向RPC來設計的，開發人員十分容易接受，所以不存在什麽適應的過程。總的來說，其實還是一個老觀念，適合的才是最好的

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

      REST對於資源型服務接口來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的接口設計帶來便利。所以我覺得純粹說什麽設計模式將會占據主導地位沒有什麽意義，關鍵還是看應用場景。

      同時很重要一點就是不要扭曲了REST，現在很多網站都跟風去開發REST風格的接口，其實都是在學其形，不知其心，最後弄得不倫不類，性能上不去，安全又保證不了，徒有一個看似像模像樣的皮囊。 

美文美圖

文章來源：