說說Web Service中REST vs RPC 的聯繫和區別

   這兩種個人理解是 RPC經常使用的soap ，REST經常使用的http（這倆名字太唬人）

摘要

Web Service 已經再也不新鮮, 而隨後的 SOA, Cloud Computing 也不斷出現, 直到百度也 提出了本身的 框計算, 咱們尚且無論這些時髦的名詞背後所蘊藏的實際的技術創新有多少, 可是他們終究是逃不出一點, 即 如何解決訪問服務的問題, 而此處的服務一般不在本地而是在遙遠的你不知道的美國或者印度.

本文想闡述標題中提到的兩種解決遠程服務訪問的方法,優缺點及其一些實際的建議等.

Contents

• 摘要

• 引入

• Web Service

• RPC

• REST

• RPC與REST的區別

• 如何選擇?

• 一個本身的項目例子

• 結論

引入

咱們天天都在使用瀏覽器來上網衝浪, 在查找本身須要的資源, HTTP協議天然是咱們使用的最多的 一種, 咱們盡情地享受着這種信息高速路的快感,卻沒有試圖去了解咱們是如何得到這些資源的? 它是一種什麼樣的設計理念?

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

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

如何訪問服務呢?

讓咱們先看看什麼是 Web Service.

Web Service

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

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

經常使用的方法有:

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

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

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

SOA 是前幾年炒的很火的一個詞, 不亞於當前的 Cloud Computing , 若是說 RPC 是基於方法調用(method),那麼 SOA 則是基於 消息, 基於方法調用一般會與特定的程序語言 耦合起來,然後者則與具體的實現語言無關, 因此在必定程度上獲得大公司的支持.

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

RPC

RPC 即遠程過程調用, 很簡單的概念, 像調用本地服務(方法)同樣調用服務器的服務(方法).一般的實現有 XML-RPC , JSON-RPC , 通訊方式基本相同, 所不一樣的只是傳輸數據的格式.

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

一個簡單的通訊過程一般爲:

Request

  member.get_username_by_id

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 的.

這裏提到的條件包括:

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等)

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, 主要基於下面幾個考慮:

1. 擴展性

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

3. 客戶端實現語言無關

4. 性能

5. 安全性(例如HTTPS)

固然上述的幾點也並不是 RPC 都不知足,不過相對而言, REST 更加清晰和簡潔, 再輔以 JSON 相應的服務會在性能和穩定性(簡單一般意味着robust)方面有很大的提升.

一個本身的項目例子

咱們公司正在作一個social game的項目, 我負責整個系統的後端架構和通訊等, 因此仔細地學習和研究了 facebook/人人網開放的API, 因爲facebook(人人網徹底拷貝facebook)使用的是REST 的架構, 因此即便facebook自己是PHP開發的,這也不妨礙咱們使用python來開發, 還有更多的PHP, Java, .net, Perl等客戶端API封裝. (固然人人網是使用Java開發的,咱們也使用python).

因而在想,假若facebook的架構使用的不是 REST ,會有這樣的靈活性嗎? 若是使用的是 RPC 可能 目前咱們的日子不會好過, 甚至咱們的項目都不可能立項!

另外,由於咱們的前端使用的是flash, 與後端的python通訊採用的是 djangoamf , 有意思的是, 若是你瞭解 flash,你會知道AMF是一種二進制的flash數據交互協議, 而 它是基於RPC ! 固然這正如我上面說的, 某些架構不是咱們可以選擇的, 因此使用 RPC 的結果是若是咱們想開放咱們遊戲的API(假如咱們的遊戲足夠火, 有朋友想基於咱們的遊戲開發周邊應用),這就變得很艱難了.可是目前來看,咱們開放API的可能性不大.

結論

不管是基於 動詞, 名詞 或者 消息, 這些都是爲咱們提供一個穩定,可靠,安全,易擴展的服務爲目的的, 因此,若是你有機會爲別的客戶端提供開放API(若是大家公司是另外一個facebook, twitter),你不妨多考慮下基於 你的平臺的開發者們, 別讓他們的日子很差過啊(同是程序員,相煎何太急?呵呵).

原文：http://www.congci.com/item/299