REST RPC架構思想

1.REST RPC是什麼？

　　REST RPC是一個改進版的RPC架構，它是爲了解決傳統的RPC和REST方案的一些不足之處而生的，它結合了REST API和RPC的優勢，同時又克服了REST API和RPC的缺點。咱們先來看看傳統的RPC和REST API方案的優勢和一些不足之處。

1.1RPC的優勢

• 屏蔽網絡細節
• 易用，和本地調用相似
• 提供靈活的API
• 支持多種協議

1.2RPC的缺點

　　傳統的RPC通常是基於protobuf或thrift去實現的，這類實現方式主要有存在這幾個問題。

• 使用麻煩，使用時須要先寫一個DSL描述文件，而後用代碼生成器生成各類語言代碼，若是model類不少的時候，這個工做就很繁瑣，工做量也較大。
• 維護性差，當某些model類須要修改時，必須從新定義和編譯，作一些繁瑣而重複的工做。
• 學習成本比較高，使用它們以前先要學習代碼生成器如何使用，還要學習複雜的DSL語法定義規則，而這些語法規則並非通用的，一段時間不用以後又要從新去學習。
• 最大問題是不能快速響應API升級，當API或者協議演進的時候，須要給客戶端提供新的SDK，當多語言的客戶端較多時，每加一個接口時都要更新一堆不一樣語言的SDK，這是維護升級的噩夢。

1.3REST API的優勢

　　輕量級，簡單易用。無須要額外的SDK，維護性和擴展性都比較好 。

1.4REST API的缺點

　　只支持http協議，使用時須要關注http協議和網絡層的細節，而http協議比較臃腫。

1.5REST RPC的特色

　　REST RPC則吸取RPC和REST API的優勢，同時又克服了他們的主要缺點，REST RPC的API和REST API相似，服務請求api是字符串形式，支持mian/sub/sub形式的API，使用方便又無須提供專門的SDK，解決了rpc模型類定義複雜繁瑣的問題，也解決了多語言sdk更新的問題。由於api是字符串弱類型的，無需專門的多語言支持的sdk包了，還能夠快速響應api和協議升級。它同時克服了rest api只能支持http協議的問題，rest rpc能夠支持多種協議，http,tcp均可以，把協議和網絡細節徹底屏蔽，使用者無需關心協議，就像本地調用同樣簡單。

2.REST RPC的實現形式

　　REST RPC的實現形式有兩種，一種基本形式和一種變體形式，變體形式是爲了克服基本形式的缺點。

2.1REST RPC基本形式

　　REST API的協議是json格式的，調用者須要先將參數序列化爲json字符串。 REST RPC的API是通用的，變化的只有服務端提供的API名稱和對應的參數對象，使用者傳入服務端提供的服務API名稱和參數對象對應的json字符串。

通用REST API原型：

string call(string service_name, string json);

•  客戶端調用：

call("handler1", "{"name":"TiMax","age":20,"city":"zhuhai"}");

• 對應的服務端處理程序：

struct Person
{
    string name;
    int age;
    string city;
};
handler1(Person p);

2.2REST RPC變體形式

　　變體形式只適用於C++或其它支持可變參數的語言，它讓RPC API使用更簡單。

　　REST RPC變體原型：

string call(string service_name, Args… args);

• 客戶端調用：

call("handler2", " TiMax", 20, "zhuhai");

• 對應的服務端處理程序

handler2(string name, int age, string city);

3.REST RPC的缺點

　　REST RPC雖然解決了REST API和RPC的大部分缺點，可是它屬於弱類型的API（字符串形式的），因此沒法在編譯期檢查接口的正確性，只能在運行期檢查API的正確性。 一個改進的作法是由客戶端的使用者封裝API，在API內部將結構體序列化爲json，再調用通用的api，這樣能夠保證在編譯期檢查API的正確性。另一個改進方式是使用REST API變體形式，但這種形式只支持C/C++等支持可變參數的語言。