從SOA說起 SOA是把專案拆成元件，每個元件暴露出服務，強調的是服務的複用。SOA架構實現不依賴於技術，因此能夠被各種不同的技術實現。 例如：SOAP, RPC，REST，DCOM，CORBA，OPC-UA，Web services，DDS，Java RMI，WCF (Microsoft's implementation of web services now forms a part of WCF)，Apache Thrift，SORCER web service是SOA最常用的一種實行方式。 WebService的常用的方法

1. RPC （遠端過程呼叫協議 ）所謂的遠端過程呼叫 (面向方法)
2. SOAP （簡單物件訪問協議） 所謂的面向服務的架構(面向訊息)
3. REST （表象化狀態轉變） 所謂的Representational state transfer (面向資源)

RPC 即遠端過程呼叫(Remote rocedure call), 很簡單的概念, 像呼叫本地服務(方法)一樣呼叫伺服器的服務(方法)。 透過向裝置了這個協定的伺服器發出請求。發出請求的使用者端一般都是需要向遠端系統要求呼叫的軟體。 通常的實現有 XML-RPC , JSON-RPC , 通訊方式基本相同, 所不同的只是傳輸資料的格式. (如果你已經習慣於XML繁重的尖括號,你不妨可以嘗試下更加輕型,高效,傳輸效率高的 JSON .) 一個簡單的通訊過程通常為: Request <?xml version="1.0"?> <methodCall> <methodName>member.get_username_by_id</methodName> <params> <param> <value><i4>1</i4></value> </param> </params> </methodCall> Response <?xml version="1.0"?> <methodResponse> <params> <param> <value><string>Zhu Tao</string></value> </param> </params> </methodResponse> 向伺服器傳送一個過程呼叫的方法及其引數, 得到伺服器返回的方法執行的結果. 在 XML-RPC 之後又有了更加強大的 SOAP , 用於一些比較複雜的系統之上。 （在新的功能不斷被引入下，這個標準慢慢演變成為今日的SOAP協定。XML-RPC協定是已登記的專利專案。）
SOAP SOAP可以看作是XML-PRC的升級版本，它是一種輕量的、簡單的基於XML的協議，允許應用程式通過HTTP或其它傳輸協議來交換資訊，SOAP是用於訪問Web Service的協議。
一個SOAP客戶端像一個桌面應用程式，它和服務端的是緊耦合的。SOAP客戶端和服務端之間維護一個共同的嚴格的契約。當客戶端的呼叫模型變更時，服務端需要變更契約以適應客戶端；當服務端的契約變更時，SOAP客戶端也必須手動或自動更新其契約，否則客戶端和服務端之間將無法通訊。
REST
REST(Representational State Transfer) 是一種軟體架構風格，REST指的是一組架構約束條件和原則，
主要有以下特點： （1）每一個URI代表一種資源； （2）客戶端和伺服器之間，傳遞這種資源的某種表現層； （3）客戶端通過四個HTTP動詞，對伺服器端資源進行操作，實現"表現層狀態轉化"。 滿足REST約束條件和原則的應用程式或設計就是 RESTful，RESTFul相比REST，多了一個ful，就英語層面來說是一個形容詞，restful翻譯為中文可以理解為：REST式的。
RESTful 風格幾乎是為 HTTP 協議量身定做的，在 HTTP 協議中用 URI 來標識唯一的資源，用 GET、PUT、POST、DELETE 等動詞來操作資源，HTTP 協議是無狀態協議，可以通過 Cache 來提高效能。
因為"資源"表示一種實體，所以應該是名詞，URI不應該有動詞，動詞應該放在HTTP協議中。 舉例來說，某個URI是/posts/show/1，其中show是動詞，這個URI就設計錯了，正確的寫法應該是/posts/1，然後用GET方法表示show。 如果某些動作是HTTP動詞表示不了的，你就應該把動作做成一種資源。比如網上匯款，從賬戶1向賬戶2匯款500元，錯誤的URI是： POST /accounts/1/transfer/500/to/2 正確的寫法是把動詞transfer改成名詞transaction，資源不能是動詞，但是可以是一種服務： POST /transaction  HTTP/1.1 Host: 127.0.0.1 　　 from=1&to=2&amount=500.00
RPC vs REST RPC是以動詞（方法）為中心的, REST是以名詞（資源）為中心的。
RPC最大的問題是耦合度高

• 客戶端需要知道服務端的方法名稱叫什麼
• 你會發現,以動詞為中心,意味著,當你要需要加入新功能時,你必須要新增更多的動詞, 這時候伺服器端需要實現相應的動詞(方法), 客戶端需要知道這個新的動詞並進行呼叫。

REST具有更高的擴充套件性和鬆耦合性 以名詞為中心, 假使我請求的是 www.site.com/books/, 無論這個URI對應的服務怎麼變化,客戶端是無需關注和更新的,而這種變化對客戶端也是透明的.
這種低耦合保證了服務端和客戶端的持續演化。
SOAP vs REST
SOAP vs. REST是一個偽命題，對它們進行直接比較並不恰當，因為SOAP（簡單物件訪問協議）是一種協議，而REST（表述性狀態轉移）是一種架構風格。 協議和架構是兩種完全不同層面的東西，協議是計算機網路中資訊交換的規則、標準和約定，其偏向於技術細節和底層；架構則是在系統層面的基準規範、通用性和原則，其偏向於抽象和頂層。一種協議可以用在不同的架構中，在架構的建設過程中也可以使用多種協議。但我還是把它們兩者拿出來進行比較，因為它們都可以用於構築Web Service。Web Service的最大作用在於其互操作性，它獨立於平臺、語言，可以讓不同的應用程式互相呼叫。 通俗地講，Web Service掃除了遠端物件或方法呼叫的障礙，它是疏通不同應用程式或伺服器之間資訊溝通的橋樑。
SOAP SOAP可以看作是XML-PRC的升級版本，它是一種輕量的、簡單的基於XML的協議，允許應用程式通過HTTP或其它傳輸協議來交換資訊，SOAP是用於訪問Web Service的協議。
REST REST是一種價格風格，不是一個標準。REST定義了一組體系架構原則，它藉助HTTP的標準方法（POST，GET，PUT，DELETE），實現了對資源的CRUD操作。
SOAP vs REST 一個SOAP客戶端像一個桌面應用程式，它和服務端的是緊耦合的。SOAP客戶端和服務端之間維護一個共同的嚴格的契約。當客戶端的呼叫模型變更時，服務端需要變更契約以適應客戶端；當服務端的契約變更時，SOAP客戶端也必須手動或自動更新其契約，否則客戶端和服務端之間將無法通訊。 一個REST客戶端更像一個瀏覽器應用程式，它和服務端是鬆耦合的。