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++等支持可变参数的语言。