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