有好多人問咱們在設計底層服務的時候究竟是應該選擇目前最流行的RestFul架構仍是選擇老牌的webService呢？今天我就將這兩個概念作一下闡述，到底什麼狀況下選擇什麼比較合理。html
首先須要瞭解：REST是一種架構風格，其核心是面向資源；而webService底層SOAP協議，主要核心是面向活動；web
相關概念：數據庫
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服務，這種使用方式是沒有意義的。less