移动API设计和实现的一些反思

在公司已经工作很久了，设计了三版的移动API。最后一个版本一直使用到现在，没有发生大的改变。

但是自己不断的在反思这些设计。

目前三个版本的API设计都是基于HTTP的JSON－RPC。有着明确的平台号，分类名和方法名，返回结果也是非常标准化的JSON格式。

经过这么久的演进和对移动开发的重新认识，发现了一些小问题。

1. 国内的网络状况并不是很理想，尤其是移动的2G。

2. 基于HTTP的JSON－RPC的主动推送性质不好，这种业务非常消耗服务器的资源。也非常消耗手机的电能。

3. 很多时间浪费在建立TCP连接上，而非传输的数据量上。

4. 再峰值的时候，大量的短连接相当于DDOS一样的攻击系统。

根据自身的业务变化，需要衡量是否所有的服务都应该继续使用HTTP的JSON－RPC。

对Thrift和Twitter的技术研究，发现Thrift的是一个很好的替代品：

1. 根据IDL生成stub代码

2. 支持多种语言

3. 比较高效的编码方式

但Thrift也有自己的问题：

1. API版本的控制问题

2. 如何进行长连接的心跳机制融入其中

3. 如何实现全双工

同时对Protocol Buffer进行了一定的研究：

1. 针对性很强，只解决编码和数据传输

2. 简单高效，手机上性能非常好

3. 无相应的函数调用机制，可自行设计全双工和心跳

根据这些研究和探索：

1. Thrift非常适合服务端的内部互访问，不太适合直接暴露给客户端使用。

2. Protocol Buffer可以在适当的地方取代JSON-RPC，来完成一些服务器主动推送给客户端的功能或对网络环境很差的时候进行使用。

对第四版本的API设计打算做以下改进：

1. 服务端内部实现功能划分，使用Thrift进行互联

2. 实现基于HTTP的JSON-RPC和基于纯TCP的Protocol Buffer双协议版本

3. 基于Protocol Buffer定义自己的全双工RPC协议