Restful 和 RPC 是什么關(guān)系

這兩個(gè)不是互斥的，HTTP是不是RPC完全取決于client的具體形式。傳統(tǒng)的RPC一般是基于二進(jìn)制協(xié)議的，client發(fā)個(gè)二進(jìn)制包過(guò)來(lái)（然后阻塞），server處理完回復(fù)一個(gè)包，client收到后醒來(lái)。在二進(jìn)制協(xié)議中一般可以在包中加個(gè)id來(lái)指明回復(fù)和請(qǐng)求的對(duì)應(yīng)關(guān)系，這樣我們就能在一個(gè)tcp連接上同時(shí)發(fā)起多個(gè)請(qǐng)求和回復(fù)。HTTP這種文本協(xié)議也可以加id，但由于一些原因（Content-Length可能缺失），即使加了id也做不到一個(gè)連接上同時(shí)傳多個(gè)HTTP消息，所以HTTP協(xié)議一般會(huì)和server保持多個(gè)連接，每個(gè)連接上同時(shí)最多只有一個(gè)HTTP消息。此種”連接池“方式即為HTTP中的”Keep-alive“。所以即使在HTTP上（或任何協(xié)議上），我們?nèi)匀豢梢宰龅礁咝У匕l(fā)送一個(gè)請(qǐng)求過(guò)去，阻塞，等待server處理完后，再醒來(lái)。這不就是RPC么。所以這兒的選擇更多是平衡功能和性能。一般來(lái)說(shuō)，面向終端用戶的盡量用Restful HTTP。原因是認(rèn)知廣，直觀，編程語(yǔ)言都支持HTTP（包括shell，這樣調(diào)試起來(lái)方便），性能不是那么重要，方便用戶share鏈接。而面向內(nèi)部系統(tǒng)的話如果機(jī)器不多也可以考慮用Restful HTTP，如果機(jī)器很多還是盡量用二進(jìn)制的RPC吧，畢竟性能差距還是很大的。

restful架構(gòu)與rpc區(qū)別

RPC

RPC 即遠(yuǎn)程過(guò)程調(diào)用， 很簡(jiǎn)單的概念， 像調(diào)用本地服務(wù)（方法）一樣調(diào)用服務(wù)器的服務(wù)（方法）。

通常的實(shí)現(xiàn)有 XML-RPC ， JSON-RPC ， 通信方式基本相同， 所不同的只是傳輸數(shù)據(jù)的格式。

（如果你已經(jīng)習(xí)慣于XML繁重的尖括號(hào)，你不妨可以嘗試下更加輕型，高效，傳輸效率高的 JSON.）

一個(gè)簡(jiǎn)單的通信過(guò)程通常為：

Request

<？xml version=“1.0”？>

member.get_username_by_id

Response

<？xml version=“1.0”？>

Zhu Tao

向服務(wù)器發(fā)送一個(gè)過(guò)程調(diào)用的方法及其參數(shù)， 得到服務(wù)器返回的方法執(zhí)行的結(jié)果。

REST

REST 不是一種協(xié)議，它是一種架構(gòu)， 一種 Web Service 能夠如果滿足 REST 的幾個(gè)條件， 通常就稱這個(gè)系統(tǒng)是 Restful 的。

這里提到的條件包括：

C/S結(jié)構(gòu) （這是Internet服務(wù)的一個(gè)基本特征）

無(wú)狀態(tài) （很熟悉吧，呵呵）

可以cache （想起了瀏覽器？）

分層系統(tǒng) （想起了無(wú)數(shù)的架構(gòu)？）

統(tǒng)一的接口 （如果這是可能的，程序員有福了， ：D）

code on demand（可選， 其實(shí)是一種擴(kuò)展性的要求）

看了這幾個(gè)特征后，你想起了什么？

你可能會(huì)破口而出： HTTP.

我答： You got it！

HTTP是WWW的最核心的協(xié)議， 它將簡(jiǎn)單的分布于世界各個(gè)角落的資源都統(tǒng)一起來(lái)， 統(tǒng)一的地址， 簡(jiǎn)單的方法， 和一定數(shù)量的表達(dá)方式。（你可能對(duì)這三點(diǎn)描述很模糊，請(qǐng)go ahead）。

REST 的三個(gè)要素是 唯一的資源標(biāo)識(shí)， 簡(jiǎn)單的方法 （此處的方法是個(gè)抽象的概念）， 一定的表達(dá)方式。

REST 是以 資源 為中心， 名詞即資源的地址， 動(dòng)詞即施加于名詞上的一些有限操作， 表達(dá)是對(duì)各種資源形態(tài)的抽象。

以HTTP為例， 名詞即為URI（統(tǒng)一資源標(biāo)識(shí)）， 動(dòng)詞包括POST， GET， PUT， DELETE等（還有其它不常用的2個(gè)，所以 整個(gè)動(dòng)詞集合是有限的）， 資源的形態(tài)（如text， html， image， pdf等）

RPC與REST的區(qū)別

如果你想只記住一點(diǎn)，那么就請(qǐng)記住 RPC是以動(dòng)詞為中心的， REST是以名詞為中心的， 此處的 動(dòng)詞指的是一些方法， 名詞是指資源。

你會(huì)發(fā)現(xiàn)，以動(dòng)詞為中心，意味著，當(dāng)你要需要加入新功能時(shí)，你必須要添加更多的動(dòng)詞， 這時(shí)候服務(wù)器端需要實(shí)現(xiàn) 相應(yīng)的動(dòng)詞（方法）， 客戶端需要知道這個(gè)新的動(dòng)詞并進(jìn)行調(diào)用。

而以名詞為中心， 假使我請(qǐng)求的是 hostname/friends/， 無(wú)論這個(gè)URI對(duì)應(yīng)的服務(wù)怎么變化，客戶端是無(wú)需 關(guān)注和更新的，而這種變化對(duì)客戶端也是透明的。

至于其它的區(qū)別，如對(duì)實(shí)現(xiàn)語(yǔ)言的依賴， 耦合性等，這些都是上面提到的這個(gè)根本區(qū)別所衍生的。

讓我們回到引入部分的2個(gè)問(wèn)題。 當(dāng)你每天使用HTTP沖浪時(shí)，你都在使用 REST 與遠(yuǎn)程的服務(wù)器進(jìn)行親密接觸。 當(dāng)你使用Gtalk和同事朋友溝通時(shí)，你則是在享受著 RPC 的便利.