Restful 和 RPC 是什么關系

這兩個不是互斥的，HTTP是不是RPC完全取決于client的具體形式。傳統的RPC一般是基于二進制協議的，client發個二進制包過來（然后阻塞），server處理完回復一個包，client收到后醒來。在二進制協議中一般可以在包中加個id來指明回復和請求的對應關系，這樣我們就能在一個tcp連接上同時發起多個請求和回復。HTTP這種文本協議也可以加id，但由于一些原因（Content-Length可能缺失），即使加了id也做不到一個連接上同時傳多個HTTP消息，所以HTTP協議一般會和server保持多個連接，每個連接上同時最多只有一個HTTP消息。此種”連接池“方式即為HTTP中的”Keep-alive“。所以即使在HTTP上（或任何協議上），我們仍然可以做到高效地發送一個請求過去，阻塞，等待server處理完后，再醒來。這不就是RPC么。所以這兒的選擇更多是平衡功能和性能。一般來說，面向終端用戶的盡量用Restful HTTP。原因是認知廣，直觀，編程語言都支持HTTP（包括shell，這樣調試起來方便），性能不是那么重要，方便用戶share鏈接。而面向內部系統的話如果機器不多也可以考慮用Restful HTTP，如果機器很多還是盡量用二進制的RPC吧，畢竟性能差距還是很大的。

restful架構與rpc區別

RPC

RPC 即遠程過程調用， 很簡單的概念， 像調用本地服務（方法）一樣調用服務器的服務（方法）。

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

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

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

Request

<？xml version=“1.0”？>

member.get_username_by_id

Response

<？xml version=“1.0”？>

Zhu Tao

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

REST

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

這里提到的條件包括：

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

無狀態 （很熟悉吧，呵呵）

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

分層系統 （想起了無數的架構？）

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

code on demand（可選， 其實是一種擴展性的要求）

看了這幾個特征后，你想起了什么？

你可能會破口而出： HTTP.

我答： You got it！

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

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