一、引入

我們每天都在使用瀏覽器來上網沖浪, 在查找自己需要的資源, HTTP協議自然是我們使用的最多的 一種, 我們盡情地享受著這種信息高速路的快感,卻沒有試圖去了解我們是如何獲得這些資源的? 它是一種什么樣的設計理念?

我們也偶爾會使用 Gtalk來和自己的同事或者朋友來聊天, 我們在給朋友提供資源(信息)的同時 也獲取著朋友的資源(信息), 我們是否可曾想過, 這種交流背后又是一種什么過程呢?

在這互聯網的時代,只要牽扯到獲得非本地的資源, 都會面臨一個問題:

如何訪問服務呢?

讓我們先看看什么是?Web Service.

二、Web Service

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

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

常用的方法有:

RPC?所謂的遠程過程調用 (面向方法)

SOA?所謂的面向服務的架構(面向消息)

REST?所謂的?Representational state transfer?(面向資源)

SOA?是前幾年炒的很火的一個詞, 不亞于當前的?Cloud Computing?, 如果說?RPC?是基于方法調用(method),那么?SOA?則是基于?消息, 基于方法調用通常會與特定的程序語言 耦合起來,而后者則與具體的實現語言無關, 所以在一定程度上得到大公司的支持.

本文不會在?SOA?上著筆過多, 主要是因為筆者本人對這個沒有多少研究, 怕誤導讀者. 另, 筆者 最近對?RPC?和?REST?方式的原理和實現有一些研究, 所以本文會主要集中在?RPC?和REST.

三、RPC

RPC?即遠程過程調用, 很簡單的概念,?像調用本地服務(方法)一樣調用服務器的服務(方法).

通常的實現有?XML-RPC?,?JSON-RPC?, 通信方式基本相同, 所不同的只是傳輸數據的格式.

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

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

Request

<?xml version="1.0"?> <methodCall> <methodName>member.get_username_by_id</methodName> <params> <param> <value><i4>1</i4></value> </param> </params> </methodCall>

Response

<?xml version="1.0"?> <methodResponse> <params> <param> <value><string>Zhu Tao</string></value> </param> </params> </methodResponse>

向服務器發送一個過程調用的方法及其參數, 得到服務器返回的方法執行的結果.

在?XML-RPC?之后又有了更加強大的?SOAP?, 用于一些比較復雜的系統之上.

四、REST

終于我們來看?REST?了, 呵呵, 這個是我目前比較喜歡的一個遠程通信方法(架構).

REST?不是一種協議,它是一種架構, 一種?Web Service?能夠如果滿足?REST?的幾個條件, 通常就稱這個系統是?Restful?的.

這里提到的條件包括:

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

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

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

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

統一的接口 (如果這是可能的,程序員有福了, :D)

code on demand(可選, 其實是一種擴展性的要求)

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

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

看下圖:

?

圖一. REST的三角架構

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

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

五、RPC與REST的區別

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

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

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

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

讓我們回到引入部分的2個問題. 當你每天使用HTTP沖浪時,你都在使用?REST?與遠程的服務器進行親密接觸. 當你使用Gtalk和同事朋友溝通時,你則是在享受著?RPC?的便利.

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

六、如何選擇?

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

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

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

擴展性

松耦合(意味著,不用強制要求客戶端去更新相應的代碼)

客戶端實現語言無關

性能

安全性(例如HTTPS)

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

轉載自：http://blog.chinaunix.net/uid-7374279-id-4612491.html

總結

以上是生活随笔為你收集整理的RPC协议与Web Service的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。