最初的程序全是單機程序，沒有網(wǎng)絡(luò)，沒有RPC，更沒有RESTful。程序猿寫的東西孤獨運行在單機上。
那時的程序猿們語言相通，參與開發(fā)同一套系統(tǒng)的團隊可以面對面溝通。
網(wǎng)絡(luò)出現(xiàn)了。網(wǎng)絡(luò)，也帶來變亂。網(wǎng)絡(luò)是不同系統(tǒng)之間的通信，無論是早期網(wǎng)絡(luò)，還是web，如何實行系統(tǒng)間的互聯(lián)互通是個頭痛的問題。
而SOA就是一種思想，就是把項目拆成組件，每個組件暴露出服務(wù)，“你調(diào)我，我調(diào)你”，大家一起把活干完。強調(diào)的是服務(wù)的相互調(diào)用。
SOA
SOA:面向服務(wù)的軟件架構(gòu)（Service Oriented Architecture）,是一種計算機軟件的設(shè)計模式，主要應用于不通應用組件中通過某種協(xié)議來互操作。例如典型的通過網(wǎng)絡(luò)協(xié)議。因此SOA是獨立于任何廠商、產(chǎn)品與技術(shù)的。
SOA作為一種架構(gòu)依賴于服務(wù)的方向，它的基本設(shè)計原理是：服務(wù)提供了一個簡單的接口，抽象了底層的復雜性，然后用戶可以訪問獨立的服務(wù)，而不需要去了解服務(wù)底層平臺實現(xiàn)。
基于SOA的解決方案，努力使經(jīng)營目標而建立企業(yè)的質(zhì)量體系。SOA架構(gòu)是五層水平：
1. 用戶界面層–這些GUI的最終用戶或應用程序訪問的應用程序/服務(wù)接口。
2. 業(yè)務(wù)流程層–這些精心設(shè)計的代表在應用方面的業(yè)務(wù)用例服務(wù)。
3. 服務(wù)層–服務(wù)合并在一起，為整個企業(yè)提供實時服務(wù)。
4. 服務(wù)組件層–用來建造服務(wù)的組件，如功能庫和技術(shù)庫，技術(shù)接口等。
5. 操作系統(tǒng)–這層包含數(shù)據(jù)模型，企業(yè)數(shù)據(jù)倉庫，技術(shù)平臺等。
正因為SOA架構(gòu)實現(xiàn)不依賴于技術(shù)，因此能夠被各種不同的技術(shù)實現(xiàn)。
例如：
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?
簡單地說, 也就是服務(wù)器如何向客戶端提供服務(wù).
webService的常用的方法有:
RPC（遠程過程調(diào)用協(xié)議）所謂的遠程過程調(diào)用 (面向方法)
SOAP（簡單對象訪問協(xié)議） 所謂的面向服務(wù)的架構(gòu)(面向消息)
REST（表象化狀態(tài)轉(zhuǎn)變） ? ? 所謂的Representational state transfer(面向資源)
下面分別作簡單介紹：
RPC：即遠程過程調(diào)用(Remote rocedure call), 很簡單的概念,像調(diào)用本地服務(wù)(方法)一樣調(diào)用服務(wù)器的服務(wù)(方法)。透過向裝置了這個協(xié)定的服務(wù)器發(fā)出HTTP請求。發(fā)出請求的用戶端一般都是需要向遠端系統(tǒng)要求呼叫的軟件。
通常的實現(xiàn)有XML-RPC,JSON-RPC, 通信方式基本相同, 所不同的只是傳輸數(shù)據(jù)的格式.
(如果你已經(jīng)習慣于XML繁重的尖括號,你不妨可以嘗試下更加輕型,高效,傳輸效率高的JSON.)
一個簡單的通信過程通常為:
Request
member.get_username_by_id
1
Response
Zhu?Tao
向服務(wù)器發(fā)送一個過程調(diào)用的方法及其參數(shù), 得到服務(wù)器返回的方法執(zhí)行的結(jié)果.
在XML-RPC之后又有了更加強大的SOAP, 用于一些比較復雜的系統(tǒng)之上。（在新的功能不斷被引入下，這個標準慢慢演變成為今日的SOAP協(xié)定。XML-RPC協(xié)定是已登記的專利項目。）
SOAP：簡單對象訪問協(xié)議（Simple Object Access Protocol）是一種標準化的通訊規(guī)范，主要用于Web服務(wù)（web service）中。
SOA 是前幾年炒的很火的一個詞, 不亞于當前的 Cloud Computing ,如果說 RPC 是基于方法調(diào)用(method),那么 SOA 則是基于 消息，基于方法調(diào)用通常會與特定的程序語言 耦合起來,而后者則與具體的實現(xiàn)語言無關(guān), 所以在一定程度上得到大公司的支持。
用一個簡單的例子來說明 SOAP 使用過程，一個 SOAP 消息可以發(fā)送到一個具有 Web Service 功能的 Web 站點，例如，一個含有房價信息的數(shù)據(jù)庫，消息的參數(shù)中標明這是一個查詢消息，此站點將返回一個 XML 格式的信息，其中包含了查詢結(jié)果（價格，位置，特點，或者其他信息）。由于數(shù)據(jù)是用一種標準化的可分析的結(jié)構(gòu)來傳遞的，所以可以直接被第三方站點所利用。
REST：表征狀態(tài)轉(zhuǎn)移（Representational State Transfer），采用Web 服務(wù)使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 將所有 Web 系統(tǒng)的服務(wù)抽象為資源，REST從資源的角度來觀察整個網(wǎng)絡(luò)，分布在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表征。
Http協(xié)議所抽象的get,post,put,delete就好比數(shù)據(jù)庫中最基本的增刪改查，而互聯(lián)網(wǎng)上的各種資源就好比數(shù)據(jù)庫中的記錄（可能這么比喻不是很好），對于各種資源的操作最后總是能抽象成為這四種基本操作，在定義了定位資源的規(guī)則以后，對于資源的操作通過標準的Http協(xié)議就可以實現(xiàn)，開發(fā)者也會受益于這種輕量級的協(xié)議。
REST是一種軟件架構(gòu)風格而非協(xié)議也非規(guī)范，是一種針對網(wǎng)絡(luò)應用的開發(fā)方式，可以降低開發(fā)的復雜性，提高系統(tǒng)的可伸縮性。
一種?Web Service?能夠如果滿足?REST?的幾個條件, 通常就稱這個系統(tǒng)是Restful的.
這里提到的條件包括:
C/S結(jié)構(gòu) (這是Internet服務(wù)的一個基本特征)
無狀態(tài) (很熟悉吧,呵呵)
可以cache (想起了瀏覽器?)
分層系統(tǒng) (想起了無數(shù)的架構(gòu)?)
統(tǒng)一的接口 (如果這是可能的,程序員有福了, :D)
code on demand(可選, 其實是一種擴展性的要求)
看了這幾個特征后,你想起了什么?
你可能會破口而出:HTTP.
我答:You got it!
HTTP是WWW的最核心的協(xié)議, 它將簡單的分布于世界各個角落的資源都統(tǒng)一起來, 統(tǒng)一的地址, 簡單的方法, 和一定數(shù)量的表達方式.(你可能對這三點描述很模糊,請go ahead).
REST的三個要素是唯一的資源標識,簡單的方法(此處的方法是個抽象的概念),一定的表達方式.
看下圖:
圖一. REST的三角架構(gòu)(摘自Restful User Experience)
REST是以資源為中心, 名詞即資源的地址, 動詞即施加于名詞上的一些有限操作, 表達是對各種資源形態(tài)的抽象.
以HTTP為例, 名詞即為URI(統(tǒng)一資源標識), 動詞包括POST, GET, PUT, DELETE等(還有其它不常用的2個,所以 整個動詞集合是有限的), 資源的形態(tài)(如text, html, image, pdf等)
Web 應用程序最重要的 REST 原則是
客戶端和服務(wù)器之間的交互在請求之間是無狀態(tài)的。從客戶端到服務(wù)器的每個請求都必須包含理解請求所必需的信息。如果服務(wù)器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態(tài)請求可以由任何可用服務(wù)器回答，這十分適合云計算之類的環(huán)境。客戶端可以緩存數(shù)據(jù)以改進性能。
在服務(wù)器端，應用程序狀態(tài)和功能可以分為各種資源。資源是一個有趣的概念實體，它向客戶端公開。資源的例子有：應用程序?qū)ο蟆?shù)據(jù)庫記錄、算法等等。每個資源都使用 URI (Universal Resource Identifier) 得到一個惟一的地址。所有資源都共享統(tǒng)一的界面，以便在客戶端和服務(wù)器之間傳輸狀態(tài)。使用的是標準的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是應用程序狀態(tài)的引擎，資源表示通過超鏈接互聯(lián)。
另一個重要的 REST 原則是分層系統(tǒng)，這表示組件無法了解它與之交互的中間層以外的組件。通過將系統(tǒng)知識限制在單個層，可以限制整個系統(tǒng)的復雜性，促進了底層的獨立性。
當 REST 架構(gòu)的約束條件作為一個整體應用時，將生成一個可以擴展到大量客戶端的應用程序。它還降低了客戶端和服務(wù)器之間的交互延遲。統(tǒng)一界面簡化了整個系統(tǒng)架構(gòu)，改進了子系統(tǒng)之間交互的可見性。REST 簡化了客戶端和服務(wù)器的實現(xiàn)。
在 RPC 樣式的架構(gòu)中，關(guān)注點在于方法，而在 REST 樣式的架構(gòu)中，關(guān)注點在于資源—— 將使用標準方法檢索并操作信息片段（使用表示的形式）。資源表示形式在表示形式中使用超鏈接互聯(lián)。
RESTful API 設(shè)計指南
參考阮老師的博客吧：http://www.ruanyifeng.com/blog/2014/05/restful_api.html
覺得這個沒有什么好說的！
RPC、SOAP、REST的區(qū)別
REST這種設(shè)計風格，它的很多思維方式與RPC是完全沖突的。
RPC的思想是把本地函數(shù)映射到API，也就是說一個API對應的是一個function，我本地有一個getAllUsers，遠程也能通過某種約定的協(xié)議來調(diào)用這個getAllUsers。至于這個協(xié)議是Socket、是HTTP還是別的什么并不重要； RPC中的主體都是動作，是個動詞，表示我要做什么。
而REST則不然，它的URL主體是資源，是個名詞。而且也僅支持HTTP協(xié)議，規(guī)定了使用HTTP Method表達本次要做的動作，類型一般也不超過那四五種。這些動作表達了對資源僅有的幾種轉(zhuǎn)化方式。 這種設(shè)計思路是反程序員直覺的，因為在本地業(yè)務(wù)代碼中仍然是一個個的函數(shù)，是動作，但表現(xiàn)在接口形式上則完全是資源的形式。 就像面向?qū)ο蟮摹溉f物皆對象」理論在習慣了純粹面向過程開發(fā)的程序員眼里顯得十分別扭一樣：我的代碼本來就是按順序、循環(huán)、分支這么運行的啊，為啥非得在很明確的結(jié)構(gòu)上封裝一層一層的基類子類接口，還要故意給兩個函數(shù)起同一個名字，調(diào)用時才選擇用哪一個呢？ 使用「萬物皆資源」的思想編寫實際項目中的API接口時，最常見的問題就是「這玩意到底是個什么資源？………………算了，我就直接寫吧，不管什么風格了」 比如，login和logout應該怎么REST化？ 比如，多條件復合搜索在GET里寫不下怎么辦？ 比如，大量資源的刪除難道要寫幾千個DELETE？ ?其實在理解了REST后，這些都不是什么無解的難題，只是思維方式要轉(zhuǎn)換一下： login和logout其實只是對session資源的創(chuàng)建和刪除； search本身就是個資源，使用POST創(chuàng)建，如果不需持久化，可以直接在Response中返回結(jié)果，如果需要（如翻頁、長期緩存等），直接保存搜索結(jié)果并303跳轉(zhuǎn)到資源地址就行了； id多到連url都寫不下的請求，應該創(chuàng)建task，用GET返回task狀態(tài)甚至執(zhí)行進度； ……等等等。
如果你想只記住一點,那么就請記住 RPC是以動詞為中心的, REST是以名詞為中心的, 此處的 動詞指的是一些方法, 名詞是指資源.
你會發(fā)現(xiàn),以動詞為中心,意味著,當你要需要加入新功能時,你必須要添加更多的動詞, 這時候服務(wù)器端需要實現(xiàn) 相應的動詞(方法), 客戶端需要知道這個新的動詞并進行調(diào)用.
而以名詞為中心, 假使我請求的是 hostname/friends/, 無論這個URI對應的服務(wù)怎么變化,客戶端是無需 關(guān)注和更新的,而這種變化對客戶端也是透明的.
至于其它的區(qū)別,如對實現(xiàn)語言的依賴, 耦合性等,這些都是上面提到的這個根本區(qū)別所衍生的.
推薦閱讀Restful User Experience(這個slide是個人認為解釋的最好的) 還有ReST vs SOA(P).
RPC與REST如何選擇?
通常如果我們是客戶端,我們基本上是沒有選擇的權(quán)利的, 服務(wù)提供商通常只有一種架構(gòu)的服務(wù).例如facebook, 人人 網(wǎng)開放的API(使用的是REST).
但是倘若我們有幸設(shè)計和實現(xiàn)自己的Web Service我們該如何選擇呢?
成熟度上：SOAP在成熟度上優(yōu)于REST
效率和易用性上：REST更勝一籌
安全性上：SOAP安全性高于REST，因為REST更關(guān)注的是效率和性能問題
總體上，因為REST模式的Web服務(wù)與復雜的SOAP和XML-RPC對比來講明顯的更加簡潔，越來越多的web服務(wù)開始采用REST風格設(shè)計和實現(xiàn)。例如，Amazon.com提供接近REST風格的Web服務(wù)進行圖書查找；雅虎提供的Web服務(wù)也是REST風格的。REST對于資源型服務(wù)接口來說很合適，同時特別適合對于效率要求很高，但是對于安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發(fā)語言的，對于安全性要求較高的接口設(shè)計帶來便利。
根據(jù)筆者自己的經(jīng)驗和心得, 建議能夠使用REST就盡量使用REST, 主要基于下面幾個考慮:
擴展性
松耦合(意味著,不用強制要求客戶端去更新相應的代碼)
客戶端實現(xiàn)語言無關(guān)
性能
安全性(例如HTTPS)
當然上述的幾點也并非RPC都不滿足,不過相對而言,REST更加清晰和簡潔, 再輔以JSON相應的服務(wù)會在性能和穩(wěn)定性(簡單通常意味著robust)方面有很大的提高。
當然，如果只是規(guī)定了一種規(guī)范，卻不理解它表相下面的思維方式，實施中又按照自己的理解隨意變動，那結(jié)果肯定是混亂不堪的。 當然，API怎么寫是開發(fā)者的自由。但如果一個API在url里放一堆動詞、資源設(shè)計混亂、各種亂用HTTP Method和Status Code，還自稱RESTful API的話，那就像你養(yǎng)了一條狗，還管它叫貓一樣。 這種混搭產(chǎn)物，不如叫它REFU吧。 （Remove Extension From Url：從url里去掉文件擴展名） 前面說了半天REST的理念和不懂REST造成的問題，但是，這并不代表REST比RPC更「高等」，更不是說不理解REST的人是落伍的。 所謂代碼風格、接口形式、各種林林總總的格式規(guī)定，其實都是為了在團隊內(nèi)部形成共識、防止個人習慣差異引起的混亂。JSON-RPC當然也是有規(guī)范的，但相比REST實在寬松太多了。 如果一個開發(fā)團隊規(guī)定必須在url里寫action，所有請求都是POST，可以嗎？當然也沒問題，只是不要拿出去標榜自己寫的是RESTful API就行。 規(guī)范最終還是為了開發(fā)者和軟件產(chǎn)品服務(wù)的，如果它能帶來便利、減少混亂，就值得用；反之，如果帶來的麻煩比解決的還多，那就犯不上純粹跟風追流行了。
所以我覺得純粹說什么設(shè)計模式將會占據(jù)主導地位沒有什么意義，關(guān)鍵還是看應用場景，正是那句老話：適合的才是最好的
ICE
ICE是分布式應用的一種比較好的解決方案，雖然現(xiàn)在也有一些比較流行的分布式應用解決方案，如微軟的.NET（以及原來的DCOM）、CORBA及WEB SERVICE等，但是這些面向?qū)ο蟮闹虚g件都存在一些不足：
.NET是微軟產(chǎn)品，只面向WINDOWS系統(tǒng)，而實際的情況是在當前的網(wǎng)絡(luò)環(huán)境下，不同的計算機會運行不同的系統(tǒng)，如LINUX上面就不可能使用.NET；
CORBA雖然在統(tǒng)一標準方面做了很多的工作，但是不同的供應商實現(xiàn)之間還是缺乏互操作性，并且目前還沒有一家供應商可以針對所有的異種環(huán)境提供所有的實現(xiàn)支持，且CORBA的實現(xiàn)比較復雜，學習及實施的成本都會比較高；
webService最要命的缺點就是他的性能問題，對于要求比較高的行業(yè)是很少會考慮webService的。
ICE的產(chǎn)生就是源于.NET、CORBA及WEB SERVICE這些中間件的不足，它可以支持不同的系統(tǒng)，如WINDOWS、LINUX等，也可以支持在多種開發(fā)語言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服務(wù)端可以是上面提到的任何一種語言實現(xiàn)的，客戶端也可以根據(jù)自己的實際情況選擇不同的語言實現(xiàn)，如服務(wù)端采用C語言實現(xiàn)，而客戶端采用JAVA語言實現(xiàn)，底層的通訊邏輯通過ICE的封裝實現(xiàn)，我們只需要關(guān)注業(yè)務(wù)邏輯。
ESB
企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的概念是從面向服務(wù)體系架構(gòu)(Service Oriented Architecture， SOA)發(fā)展而來的。SOA描述了一種IT基礎(chǔ)設(shè)施的應用集成模型；其中的軟構(gòu)件集是以一種定義清晰的層次化結(jié)構(gòu)相互耦合。一個ESB是一個預先組裝的SOA實現(xiàn)，它包含了實現(xiàn)SOA分層目標所必需的基礎(chǔ)功能部件。
在企業(yè)計算領(lǐng)域，企業(yè)服務(wù)總線是指由中間件基礎(chǔ)設(shè)施產(chǎn)品技術(shù)實現(xiàn)的、 通過事件驅(qū)動和基于XML消息引擎，為更復雜的面向服務(wù)的架構(gòu)提供的軟件架構(gòu)的構(gòu)造物。企業(yè)服務(wù)總線通常在企業(yè)消息系統(tǒng)上提供一個抽象層，使得集成架構(gòu)師能夠不用編碼而是利用消息的價值完成集成工作。
企業(yè)服務(wù)總線提供可靠消息傳輸，服務(wù)接入，協(xié)議轉(zhuǎn)換，數(shù)據(jù)格式轉(zhuǎn)換，基于內(nèi)容的路由等功能，屏蔽了服務(wù)的物理位置，協(xié)議和數(shù)據(jù)格式。
ESB與EAI區(qū)別：
ESB是將所有的系統(tǒng)的交互都放在SOA統(tǒng)一服務(wù)總線上面來控制處理。
EAI只是將不同的系統(tǒng)集成起來（可以采用ESB總線形式，也可以采用點對點的形式）。
ESB解決的問題
當你的應用像下面一樣時，這個時候就需要考慮使用ESB了，如圖：
各個應用系統(tǒng)之間的調(diào)用形成了一張網(wǎng)，沒有邏輯，隨著業(yè)務(wù)的增加，維護簡直就是一場惡夢。
各個應用的邏輯很清晰，每個應用都只需要關(guān)心如何暴露自己的服務(wù)，而調(diào)用的應用只需要知道如何調(diào)用服務(wù)，至于怎么做，去找誰，則完全交給ESB來完成。
參考資料：
三種主流的Web服務(wù)實現(xiàn)方案（REST+SOAP+XML-RPC）簡述及比較
談?wù)勛约簩EST、SOA、SOAP、RPC、ICE、ESB、BPM知識匯總及理解
Restful api詳解和rpc api 區(qū)別 （原文鏈接沒有搜到，谷歌找到的是轉(zhuǎn)
文章首發(fā)：透析SOA、RPC、SOAP、REST、ICE、ESB模型發(fā)展史 - SOA架構(gòu)師成長之路 - 周陸軍的個人網(wǎng)站轉(zhuǎn)載注明來源
