最初的程式全是單機程式，沒有網路，沒有RPC，更沒有RESTful。程式猿寫的東西孤獨執行在單機上。

那時的程式猿們語言相通，參與開發同一套系統的團隊可以面對面溝通。

網路出現了。網路，也帶來變亂。網路是不同系統之間的通訊，無論是早期網路，還是web，如何實行系統間的互聯互通是個頭痛的問題。

而SOA就是一種思想，就是把專案拆成元件，每個元件暴露出服務，“你調我，我調你”，大家一起把活幹完。強調的是服務的相互呼叫。

 

SOA

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

 

SOA作為一種架構依賴於服務的方向，它的基本設計原理是：服務提供了一個簡單的介面，抽象了底層的複雜性，然後使用者可以訪問獨立的服務，而不需要去了解服務底層平臺實現。

基於SOA的解決方案，努力使經營目標而建立企業的質量體系。SOA架構是五層水平：

    1. 使用者介面層–這些GUI的終端使用者或應用程式訪問的應用程式/服務介面。

    2. 業務流程層–這些精心設計的代表在應用方面的業務用例服務。

    3. 服務層–服務合併在一起，為整個企業提供實時服務。

    4. 服務元件層–用來建造服務的元件，如功能庫和技術庫，技術介面等。

    5. 作業系統–這層包含資料模型，企業資料倉庫，技術平臺等。

 

正因為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很常用的一種實行方式。

Web Service

Web Service 也提出了好久了, 那麼究竟什麼是 

Web Service ?

簡單地說, 也就是伺服器如何向客戶端提供服務.

 

 

webService的常用的方法有:

1. RPC   （遠端過程呼叫協議 ）所謂的遠端過程呼叫 (面向方法)

2. SOAP   （簡單物件訪問協議） 所謂的面向服務的架構(面向訊息)

3. REST （表象化狀態轉變）     所謂的 Representational state transfer (面向資源)

下面分別作簡單介紹：

 

RPC：即遠端過程呼叫(Remote rocedure call), 很簡單的概念, 像呼叫本地服務(方法)一樣呼叫伺服器的服務(方法)。透過向裝置了這個協定的伺服器發出HTTP請求。發出請求的使用者端一般都是需要向遠端系統要求呼叫的軟體。

通常的實現有 XML-RPC , JSON-RPC , 通訊方式基本相同, 所不同的只是傳輸資料的格式.

(如果你已經習慣於XML繁重的尖括號,你不妨可以嘗試下更加輕型,高效,傳輸效率高的 JSON.)

一個簡單的通訊過程通常為:

Request

  member.get_username_by_id              1

Response

              Zhu Tao

向伺服器傳送一個過程呼叫的方法及其引數, 得到伺服器返回的方法執行的結果.

在 XML-RPC 之後又有了更加強大的 SOAP , 用於一些比較複雜的系統之上。（在新的功能不斷被引入下，這個標準慢慢演變成為今日的SOAP協定。XML-RPC協定是已登記的專利專案。）

 

SOAP：簡單物件訪問協議（Simple Object Access Protocol）是一種標準化的通訊規範，主要用於Web服務（web service）中。

SOA 是前幾年炒的很火的一個詞, 不亞於當前的 Cloud Computing , 如果說 RPC 是基於方法呼叫(method),那麼 SOA 則是基於 訊息，基於方法呼叫通常會與特定的程式語言 耦合起來,而後者則與具體的實現語言無關, 所以在一定程度上得到大公司的支援。

用一個簡單的例子來說明 SOAP 使用過程，一個 SOAP 訊息可以傳送到一個具有 Web Service 功能的 Web 站點，例如，一個含有房價資訊的資料庫，訊息的引數中標明這是一個查詢訊息，此站點將返回一個 XML 格式的資訊，其中包含了查詢結果（價格，位置，特點，或者其他資訊）。由於資料是用一種標準化的可分析的結構來傳遞的，所以可以直接被第三方站點所利用。

 

REST：表徵狀態轉移（Representational State Transfer），採用Web 服務使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 將所有 Web 系統的服務抽象為資源，REST從資源的角度來觀察整個網路，分佈在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表徵。

Http協議所抽象的get,post,put,delete就好比資料庫中最基本的增刪改查，而網際網路上的各種資源就好比資料庫中的記錄（可能這麼比喻不是很好），對於各種資源的操作最後總是能抽象成為這四種基本操作，在定義了定位資源的規則以後，對於資源的操作通過標準的Http協議就可以實現，開發者也會受益於這種輕量級的協議。

REST是一種軟體架構風格而非協議也非規範，是一種針對網路應用的開發方式，可以降低開發的複雜性，提高系統的可伸縮性。

一種 Web Service 能夠如果滿足 REST 的幾個條件, 通常就稱這個系統是 Restful 的.

這裡提到的條件包括:

1. C/S結構 (這是Internet服務的一個基本特徵)

2. 無狀態 (很熟悉吧,呵呵)

3. 可以cache (想起了瀏覽器?)

4. 分層系統 (想起了無數的架構?)

5. 統一的介面 (如果這是可能的,程式設計師有福了, :D)

6. code on demand(可選, 其實是一種擴充套件性的要求)

看了這幾個特徵後,你想起了什麼?

你可能會破口而出: HTTP.

我答: You got it!

HTTP是WWW的最核心的協議, 它將簡單的分佈於世界各個角落的資源都統一起來, 統一的地址, 簡單的方法, 和一定數量的表達方式.(你可能對這三點描述很模糊,請go ahead).

REST 的三個要素是 唯一的資源標識, 簡單的方法 (此處的方法是個抽象的概念), 一定的表達方式.

看下圖:

圖一. REST的三角架構(摘自 Restful User Experience )

REST 是以 資源 為中心, 名詞即資源的地址, 動詞即施加於名詞上的一些有限操作, 表達是對各種資源形態的抽象.

以HTTP為例, 名詞即為URI(統一資源標識), 動詞包括POST, GET, PUT, DELETE等(還有其它不常用的2個,所以 整個動詞集合是有限的), 資源的形態(如text, html, image, pdf等)

Web 應用程式最重要的 REST 原則是

客戶端和伺服器之間的互動在請求之間是無狀態的。從客戶端到伺服器的每個請求都必須包含理解請求所必需的資訊。如果伺服器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態請求可以由任何可用伺服器回答，這十分適合雲端計算之類的環境。客戶端可以快取資料以改進效能。

 

在伺服器端，應用程式狀態和功能可以分為各種資源。資源是一個有趣的概念實體，它向客戶端公開。資源的例子有：應用程式物件、資料庫記錄、演算法等等。每個資源都使用 URI (Universal Resource Identifier) 得到一個惟一的地址。所有資源都共享統一的介面，以便在客戶端和伺服器之間傳輸狀態。使用的是標準的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是應用程式狀態的引擎，資源表示通過超連結互聯。

 

另一個重要的 REST 原則是分層系統，這表示元件無法瞭解它與之互動的中間層以外的元件。通過將系統知識限制在單個層，可以限制整個系統的複雜性，促進了底層的獨立性。

 

當 REST 架構的約束條件作為一個整體應用時，將生成一個可以擴充套件到大量客戶端的應用程式。它還降低了客戶端和伺服器之間的互動延遲。統一介面簡化了整個系統架構，改進了子系統之間互動的可見性。REST 簡化了客戶端和伺服器的實現。

 

在 RPC 樣式的架構中，關注點在於方法，而在 REST 樣式的架構中，關注點在於資源 —— 將使用標準方法檢索並操作資訊片段（使用表示的形式）。資源表示形式在表示形式中使用超連結互聯。

 

RESTful API 設計指南

參考阮老師的部落格吧：http://www.ruanyifeng.com/blog/2014/05/restful_api.html

覺得這個沒有什麼好說的！

RPC、SOAP、REST的區別

REST這種設計風格，它的很多思維方式與RPC是完全衝突的。

 RPC的思想是把本地函式對映到API，也就是說一個API對應的是一個function，我本地有一個getAllUsers，遠端也能通過某種約定的協議來呼叫這個getAllUsers。至於這個協議是Socket、是HTTP還是別的什麼並不重要； RPC中的主體都是動作，是個動詞，表示我要做什麼。

 而REST則不然，它的URL主體是資源，是個名詞。而且也僅支援HTTP協議，規定了使用HTTP Method表達本次要做的動作，型別一般也不超過那四五種。這些動作表達了對資源僅有的幾種轉化方式。 這種設計思路是反程式設計師直覺的，因為在本地業務程式碼中仍然是一個個的函式，是動作，但表現在介面形式上則完全是資源的形式。 就像面向物件的「萬物皆物件」理論在習慣了純粹面向過程開發的程式設計師眼裡顯得十分別扭一樣：我的程式碼本來就是按順序、迴圈、分支這麼執行的啊，為啥非得在很明確的結構上封裝一層一層的基類子類介面，還要故意給兩個函式起同一個名字，呼叫時才選擇用哪一個呢？ 使用「萬物皆資源」的思想編寫實際專案中的API介面時，最常見的問題就是「這玩意到底是個什麼資源？………………算了，我就直接寫吧，不管什麼風格了」 比如，login和logout應該怎麼REST化？ 比如，多條件複合搜尋在GET裡寫不下怎麼辦？ 比如，大量資源的刪除難道要寫幾千個DELETE？  其實在理解了REST後，這些都不是什麼無解的難題，只是思維方式要轉換一下： login和logout其實只是對session資源的建立和刪除； search本身就是個資源，使用POST建立，如果不需持久化，可以直接在Response中返回結果，如果需要（如翻頁、長期快取等），直接儲存搜尋結果並303跳轉到資源地址就行了； id多到連url都寫不下的請求，應該建立task，用GET返回task狀態甚至執行進度； ……等等等。 

 

如果你想只記住一點,那麼就請記住 RPC是以動詞為中心的, REST是以名詞為中心的, 此處的 動詞指的是一些方法, 名詞是指資源.

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

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

 

至於其它的區別,如對實現語言的依賴, 耦合性等,這些都是上面提到的這個根本區別所衍生的.

 

推薦閱讀 Restful User Experience (這個slide是個人認為解釋的最好的) 還有 ReST vs SOA(P).

RPC與REST如何選擇?

通常如果我們是客戶端,我們基本上是沒有選擇的權利的, 服務提供商通常只有一種架構的服務.例如facebook, 人人 網開放的API(使用的是 REST ).

但是倘若我們有幸設計和實現自己的 Web Service 我們該如何選擇呢?

成熟度上：SOAP在成熟度上優於REST

效率和易用性上：REST更勝一籌

安全性上：SOAP安全性高於REST，因為REST更關注的是效率和效能問題

總體上，因為REST模式的Web服務與複雜的SOAP和XML-RPC對比來講明顯的更加簡潔，越來越多的web服務開始採用REST風格設計和實現。例如，Amazon.com提供接近REST風格的Web服務進行圖書查詢；雅虎提供的Web服務也是REST風格的。REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。

根據筆者自己的經驗和心得, 建議 能夠使用REST就儘量使用REST, 主要基於下面幾個考慮:

1. 擴充套件性

2. 鬆耦合(意味著,不用強制要求客戶端去更新相應的程式碼)

3. 客戶端實現語言無關

4. 效能

5. 安全性(例如HTTPS)

當然上述的幾點也並非 RPC 都不滿足,不過相對而言, REST 更加清晰和簡潔, 再輔以 JSON 相應的服務會在效能和穩定性(簡單通常意味著robust)方面有很大的提高。

 

當然，如果只是規定了一種規範，卻不理解它表相下面的思維方式，實施中又按照自己的理解隨意變動，那結果肯定是混亂不堪的。 當然，API怎麼寫是開發者的自由。但如果一個API在url裡放一堆動詞、資源設計混亂、各種亂用HTTP Method和Status Code，還自稱RESTful API的話，那就像你養了一條狗，還管它叫貓一樣。 這種混搭產物，不如叫它REFU吧。 （Remove Extension From Url：從url裡去掉副檔名） 前面說了半天REST的理念和不懂REST造成的問題，但是，這並不代表REST比RPC更「高等」，更不是說不理解REST的人是落伍的。 所謂程式碼風格、介面形式、各種林林總總的格式規定，其實都是為了在團隊內部形成共識、防止個人習慣差異引起的混亂。JSON-RPC當然也是有規範的，但相比REST實在寬鬆太多了。 如果一個開發團隊規定必須在url裡寫action，所有請求都是POST，可以嗎？當然也沒問題，只是不要拿出去標榜自己寫的是RESTful API就行。 規範最終還是為了開發者和軟體產品服務的，如果它能帶來便利、減少混亂，就值得用；反之，如果帶來的麻煩比解決的還多，那就犯不上純粹跟風追流行了。

所以我覺得純粹說什麼設計模式將會佔據主導地位沒有什麼意義，關鍵還是看應用場景，正是那句老話：適合的才是最好的

 

 

 

ICE

ICE是分散式應用的一種比較好的解決方案，雖然現在也有一些比較流行的分散式應用解決方案，如微軟的.NET（以及原來的DCOM）、CORBA及WEB SERVICE等，但是這些面向物件的中介軟體都存在一些不足：

 .NET是微軟產品，只面向WINDOWS系統，而實際的情況是在當前的網路環境下，不同的計算機會執行不同的系統，如LINUX上面就不可能使用.NET；

 CORBA雖然在統一標準方面做了很多的工作，但是不同的供應商實現之間還是缺乏互操作性，並且目前還沒有一家供應商可以針對所有的異種環境提供所有的實現支援，且CORBA的實現比較複雜，學習及實施的成本都會比較高；

 webService最要命的缺點就是他的效能問題，對於要求比較高的行業是很少會考慮 webService的。

 ICE的產生就是源於.NET、CORBA及WEB SERVICE這些中介軟體的不足，它可以支援不同的系統，如WINDOWS、LINUX等，也可以支援在多種開發語言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服務端可以是上面提到的任何一種語言實現的，客戶端也可以根據自己的實際情況選擇不同的語言實現，如服務端採用C語言實現，而客戶端採用JAVA語言實現，底層的通訊邏輯通過ICE的封裝實現，我們只需要關注業務邏輯。

ESB

企業服務匯流排（Enterprise Service Bus，ESB）的概念是從面向服務體系架構(Service Oriented Architecture， SOA)發展而來的。SOA描述了一種IT基礎設施的應用整合模型；其中的軟構件集是以一種定義清晰的層次化結構相互耦合。一個ESB是一個預先組裝的SOA實現，它包含了實現SOA分層目標所必需的基礎功能部件。

在企業計算領域，企業服務匯流排是指由中介軟體基礎設施產品技術實現的、 通過事件驅動和基於XML訊息引擎，為更復雜的面向服務的架構提供的軟體架構的構造物。企業服務匯流排通常在企業訊息系統上提供一個抽象層，使得整合架構師能夠不用編碼而是利用訊息的價值完成整合工作。

企業服務匯流排提供可靠訊息傳輸，服務接入，協議轉換，資料格式轉換，基於內容的路由等功能，遮蔽了服務的物理位置，協議和資料格式。

ESB與EAI區別：

ESB是將所有的系統的互動都放在SOA統一服務總線上面來控制處理。

EAI只是將不同的系統整合起來（可以採用ESB匯流排形式，也可以採用點對點的形式）。

 

 

ESB解決的問題

當你的應用像下面一樣時，這個時候就需要考慮使用ESB了，如圖：

各個應用系統之間的呼叫形成了一張網，沒有邏輯，隨著業務的增加，維護簡直就是一場惡夢。

 

各個應用的邏輯很清晰，每個應用都只需要關心如何暴露自己的服務，而呼叫的應用只需要知道如何呼叫服務，至於怎麼做，去找誰，則完全交給ESB來完成。

 

參考資料：

三種主流的Web服務實現方案（REST+SOAP+XML-RPC）簡述及比較

Web Service實踐之REST vs RPC

談談自己對REST、SOA、SOAP、RPC、ICE、ESB、BPM知識彙總及理解

如何選擇ESB

Restful api詳解和rpc api 區別 （原文連結沒有搜到，谷歌找到的是轉