REST、SOA、SOAP、RPC

SOA: 

面向服務的軟件架構（Service Oriented Architecture）,是一種計算機軟件的設計模式，主要應用於不通應用組件中經過某種協議來互操做，例如典型的經過網絡協議。所以SOA是獨立於任何廠商、產品與技術的。

所以REST、SOAP、RPC、RMI、DCOM等都是SOA的一種實現而已。

 

 

 SOAP:

SOAP (Simple Object Access Protocol) 顧名思義，是一個嚴格定義的信息交換協議，用於在Web Service中把遠程調用和返回封裝成機器可讀的格式化數據。事實上SOAP數據使用XML數據格式，定義了一整套複雜的標籤，以描述調用的遠程過程、參數、返回值和出錯信息等等。並且隨着須要的增加，又不得增長協議以支持安全性，這使SOAP變得異常龐大，背離了簡單的初衷。另外一方面，各個服務器均可以基於這個協議推出本身的API，即便它們提供的服務及其類似，定義的API也不盡相同，這又致使了WSDL的誕生。WSDL (Web Service Description Language) 也遵循XML格式，用來描述哪一個服務器提供什麼服務，怎樣找到它，以及該服務使用怎樣的接口規範，簡言之，服務發現。如今，使用Web Service的過程變成，得到該服務的WSDL描述，根據WSDL構造一條格式化的SOAP請求發送給服務器，而後接收一條一樣SOAP格式的應答，最後根據先前的WSDL解碼數據。絕大多數狀況下，請求和應答使用HTTP協議傳輸，那麼發送請求就使用HTTP的POST方法。

SOAP = HTTP+XML+RPC
對於RPC自己能夠走HTTP ,TCP等不一樣的協議，好比淘寶的Dubbo框架，RPC是能夠選擇走TCP協議仍是走HTTP協議的。

 

REST (REpresentational State Transfort) 形式上應該表述爲客戶端經過申請資源來實現狀態的轉換，在這個角度系統能夠當作一臺虛擬的狀態機。REST應該知足這樣的特色：1)客戶端和服務器結構；2)鏈接協議具備無狀態性；3)可以利用Cache機制增進性能；4)層次化的系統；

說到底，REST只是一種架構風格，而不是協議或標準。但這種新的風格（也許已經歷史悠久？）對現有的以SOAP爲表明的Web Service形成的衝擊也是革命性的，由於它面向資源，甚至連服務也抽象成資源，由於它和HTTP緊密結合，由於它服務器無狀態。

無狀態通訊，是指服務端(響應端)不保存任何與特定HTTP請求相關的資源，應用狀態必須由請求方在請求過程當中提供。要求在網絡通訊過程當中，任意一個Web請求必須與其餘請求隔離，當請求端提出請求時，請求自己包含了響應端爲響應這一請求所需的所有信息。

https://blog.csdn.net/Jmilk/article/details/50461577

RPC（Remote Procedure Call Protocol）——遠程過程調用協議，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，爲通訊程序之間攜帶信息數據。在OSI網絡通訊模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易。

一般的實現有 XML-RPC ， JSON-RPC ， 通訊方式基本相同， 所不一樣的只是傳輸數據的格式。

 

REST 不是一種協議，它是一種架構， 一種 Web Service 可以若是知足 REST 的幾個條件， 一般就稱這個系統是 Restful 的。

 

RPC框架與具體的協議無關。RPC 可基於 HTTP 或 TCP 協議，Web Service 就是基於 HTTP 協議的 RPC，它具備良好的跨平臺性，但其性能卻不如基於 TCP 協議的 RPC。

1. TCP/HTTP：衆所周知，TCP 是傳輸層協議，HTTP 是應用層協議，而傳輸層較應用層更加底層，在數據傳輸方面，越底層越快，所以，在通常狀況下，TCP 必定比 HTTP 快。

 

RPC是以動詞爲中心的， REST是以名詞爲中心的， 此處的 動詞指的是一些方法， 名詞是指資源。

你會發現，以動詞爲中心，意味着，當你要須要加入新功能時，你必需要添加更多的動詞， 這時候服務器端須要實現 相應的動詞（方法）， 客戶端須要知道這個新的動詞並進行調用。

而以名詞爲中心， 假使我請求的是 hostname/friends/， 不管這個URI對應的服務怎麼變化，客戶端是無需 關注和更新的，而這種變化對客戶端也是透明的。

 

Dubbo
HSF

Mesh