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++等支持可變參數的語言。