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