有好多人問我們在設計底層服務的時候到底是應該選擇目前最流行的RestFul架構還是選擇老牌的webService呢？今天我就將這兩個概念做一下闡述，到底什么情況下選擇什么比較合理。
首先需要了解：REST是一種架構風格，其核心是面向資源；而webService底層SOAP協議，主要核心是面向活動；
相關概念：
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專門針對網絡應用設計和開發方式，以降低開發的復雜性，提高系統的可伸縮性。REST提出設計概念和准則為：
1. 網絡上的所有事物都可以被抽象為資源(resource)
2. 每一個資源都有唯一的資源標識(resource identifier)，對資源的操作不會改變這些標識
3. 所有的操作都是無狀態的
REST簡化開發，其架構遵循CRUD原則，該原則告訴我們對於資源(包括網絡資源)只需要四種行為：創建，獲取，更新和刪除就可以完成相關的操作和處理。我們可以通過統一資源標識符（Universal Resource Identifier，URI）來識別和定位資源，並且針對這些資源而執行的操作是通過 HTTP 規范定義的。其核心操作只有GET,PUT,POST,DELETE。由於REST強制所有的操作都必須是stateless的，這就沒有上下文的約束，如果做分布式，集群都不需要考慮上下文和會話保持的問題。極大的提高系統的可伸縮性。
SOAP webService有嚴格的規范和標准，包括安全，事務等各個方面的內容，同時SOAP強調操作方法和操作對象的分離，有WSDL文件規范和XSD文件分別對其定義。
如果從這個意義上講，是否使用REST就需要考慮資源本身的抽象和識別是否困難，如果本身就是簡單的類似增刪改查的業務操作，那么抽象資源就比較容易，而對於復雜的業務活動抽象資源並不是一個簡單的事情。比如校驗用戶等級，轉賬，事務處理等，這些往往並不容易簡單的抽象為資源。
其次如果有嚴格的規范和標准定義要求，而且前期規范標准需要指導多個業務系統集成和開發的時候，SOAP風格由於有清晰的規范標准定義是明顯有優勢的。我們可以在開始和實現之前就嚴格定義相關的接口方法和接口傳輸數據。（很多情況下是為了兼容以前項目且前台調用邏輯代碼都不能動的前提下，更改底層應用，一般就需要使用webService模式開發，因為老代碼中已經有了明確的方法定義以及參數類型、個數等申明）
簡單數據操作，無事務處理，開發和調用簡單這些是使用REST架構風格的優勢。而對於較為復雜的面向活動的服務，如果我們還是使用REST，很多時候都是仍然是傳統的面向活動的思想通過轉換工具再轉換得到REST服務，這種使用方式是沒有意義的。