你想要的都在這之RPC/web service/REST/SOA區別聯系與對比

關於架構方面有很多名詞，有點暈頭轉向了（集中梳理一下，記錄以便查看）：RPC/web service/REST/SOA/SOAP，這篇文章將會做以下幾點：

1.歸類，從屬關系

2.區別與聯系

3.應用場景及優缺點

 

-----------------------------------

先對上面的名詞做一個概要介紹：

1. RPC ,遠程過程調用 (面向方法)，你可以這么理解，就是在另外一台服務器上有一段代碼（函數），你可以通過網絡遠程調用它。用什么協議（http，tcp，udp…），傳輸什么數據格式（json，xml，二進制…）你都可以自己定義。很簡單的概念, 像調用本地服務(方法)一樣調用服務器的服務(方法)。
2. SOA ,面向服務的架構(面向消息)，SOA是一種架構方法（SOA不是Web Service，Web Service是目前最適合實現SOA的技術。）
3. REST , Representational state transfer遠程過程調用 (面向資源)
4. web service顧名思義這是一種提供service的形式，而且只能通過http（web）來提供service(web service三要素：SOAP、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscovery andIntegration))
5. SOAP,簡單對象訪問協議,是一種輕量的、簡單的、基於XML（標准通用標記語言下的一個子集）的協議，它被設計成在WEB上交換結構化的和固化的信息。
6. SOAP和RPC都是web service的實現方式

RPC與SOA的區別

總的來講：RPC是一種進程遠程調用的方式，更強調的是異構平台之間進程通信的機制。SOA是一種產品架構的理念，以服務為中心，松耦合，通過定義嚴謹明確的接口進行通信。有比較完善的服務管理機制。

兩者並不是一個層面上的概念，可以說RPC是SOA架構的一種實現。

 

RPC與REST的區別

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

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

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

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

當你每天使用HTTP沖浪時,你都在使用 REST 與遠程的服務器進行親密接觸. 當你使用Gtalk和同事朋友溝通時,你則是在享受着 RPC 的便利.

　　 場景及選擇：

比如公司要做一個社交游戲的項目, 讓你去負責整個系統的后端架構和通信等, 我們就有必要去仔細地學習和研究下facebook/人人網/新浪等社交網站（游戲）開放的API, 我們知道facebook使用的是REST 的架構, 所以即使facebook本身是PHP開發的,這也不妨礙我們使用python來開發, 還有更多的PHP, Java, .net, Perl等客戶端API封裝.這樣就能靈活的適配多端的服務了。

於是在想,倘若facebook的架構使用的不是 REST ,會有這樣的靈活性嗎? 如果使用的是 RPC 可能不會有這么便利。

另外,因為我們的前端使用的是flash, 與后端的python通信采用的是 Django+Flex+AMF , 如果你了解 flash,你會知道AMF是一種二進制的flash數據交互協議, 而 它是基於RPC !

所以，我們需要根據當前需求的情況來選擇REST或則RPC

 

 

REST與SOAP的區別

國外很多大網站都發布了自己的開發API，很多都提供了SOAP和REST兩種Web Service，根據調查部分網站的REST風格的使用情況要高於SOAP。但是由於REST只是一種基於Http協議實現資源操作的思想，因此各個網站的REST實現都自有一套，在后面會講訴各個大網站的REST API的風格。也正是因為這種各自實現的情況，在性能和可用性上會大大高於SOAP發布的web service，但統一通用方面遠遠不及SOAP。由於這些大網站的SP往往專注於此網站的API開發，因此通用性要求不高。 

 

SOAP協議對於消息體和消息頭都有定義，同時消息頭的可擴展性為各種互聯網的標准提供了擴展的基礎，WS-*系列就是較為成功的規范。但是也由於SOAP由於各種需求不斷擴充其本身協議的內容，導致在SOAP處理方面的性能有所下降。同時在易用性方面以及學習成本上也有所增加。 
       REST被人們的重視，其實很大一方面也是因為其高效以及簡潔易用的特性。這種高效一方面源於其面向資源接口設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。同時，在我看來REST還有一個很吸引開發者的就是能夠很好的融合當前Web2.0的很多前端技術來提高開發效率。例如很多大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml作為數據承載，還有（JSON,RSS,ATOM）等形式，這對很多網站前端開發人員來說就能夠很好的mashup各種資源信息。 
       因此在效率和易用性上來說，REST更勝一籌。 

　　 REST對於資源型服務接口來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的接口設計帶來便利。所以我覺得純粹說什么設計模式將會占據主導地位沒有什么意義，關鍵還是看應用場景。 

 

說了這么多，到最后我發現，其實不必要太糾結這些概念，這些概念有些是相互關聯的，有些優勢包含關系，在實際場景中去使用，去研究。