最初的程序全是單機程序，沒有網絡，沒有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的常用的方法有:

RPC （遠程過程調用協議）所謂的遠程過程調用 (面向方法)
SOAP （簡單對象訪問協議）所謂的面向服務的架構(面向消息)
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 的.

這裏提到的條件包括:

C/S結構 (這是Internet服務的一個基本特徵)
無狀態 (很熟悉吧,呵呵)
可以cache (想起了瀏覽器?)
分層系統 (想起了無數的架構?)
統一的接口 (如果這是可能的,程序員有福了, :D)
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, 主要基於下面幾個考慮:

擴展性
鬆耦合(意味着,不用強制要求客戶端去更新相應的代碼)
客戶端實現語言無關
性能
安全性(例如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總線形式，也可以採用點對點的形式）。