程序员的自我救赎---11.1：RPC接口使用规范

《前言》

（一） Winner2.0 框架基础分析

（二）PLSQL报表系统

（三）SSO单点登录

（四） 短信中心与消息中心

（五）钱包系统

（六）GPU支付中心

（七）权限系统

（八）监控系统

（九）会员中心

（十） APP版本控制系统

（十一）Winner前端框架与RPC接口规范讲解

（十二）上层应用案例

（十三）总结

《RPC接口使用规范》

不知道啥时候开始好像一下子都流行叫“RPC”了。之前我们都叫“API”的，为此我特地百度了一下才知道原来：

API（Application Programming Interface，应用程序编程接口）

RPC（Remote Procedure Call），远程过程调用）

这样一看确实叫RPC更合适一下，细致讲一下我们Winner2.0中接口请求规范，我们从简到繁的说一下演变过程（以下就简称RPC）。

首先在1.0时代，我们当时也没有很多思路，只做了简单签名验证也没有考虑权限、版本等问题，主要是用WebService。

我们看一下常规情况我们是这么用的：

我们的目的是为了防止WebService 接口被恶意调用，尤其是篡改数据后调用所以用了两种手段做安全验证：

1，使用RSA对参数加密（RSA是非对称加密，公钥加密私钥解密，一般使用两对RSA）。

2，使用MD5做签名验证（客户端与服务端约定一个字符串做加密种子，将所有参数+加密种子 算出来唯一的md5值）

这样做基本对于安全性而言已经够了，但是在使用过程中五六年下来总是觉得用着不顺手。大致几点如下：

A，接口没有权限管制。比如我们一个接口同时有A、B两个项目调用，这个时候我想停止给B项目使用，接口就没有控制权。

这种情况经常出现在给第三方调用时候，我们不想给第三方使用了，这个时候又关不掉，关掉了我们自己的项目也用不了了。

B，我们这样写接口没有版本的概念。同样以第三方调用我们的接口来举例，如果我们升级项目更改了参数，所有的第三方就开始

骂娘了，每个第三方客户端都要去升级系统，而且我们一刀切调用不见得有时间来配合我们升级。有版本号的话，我们可以让老用户

依然可以继续使用，新接入的就使用最新的接口。

C，对于移动客户端没有管理概念。 这个属于特殊的业务，我们公司的硬件终端如果我想限制某一台终端调用，之前的做法是不行的。

D：参数过多时代码繁琐。 如果9个参数，客户端就要给8个参数依次加密，当然可以写工具类处理，但还是繁琐了。

F：没有统一的Json返回参数规范。每个项目都是自己定义返回结果，没有规范。客户端开发时没有规律可循。

另外还有一些小问题，但最主要的就这几点，所以我们在Winner2.0中我们商量出了一套标准，所有的接口基于这套标准开发。

首先，得益于MVC的到来，我们基本放弃了使用Webservice这种方式提供接口，转而使用WebAPI的形式。

其次，我们接口只接收三个固定参数：商户号，Json数据，签名字符串。

最后，我们统一了返回Json的数据标准，以及错误编码。

这里我贴一张Jason 写的接口文档中的接口API协议：

公共参数就是所有接口都需要接收这些基本的参数，再一个子Json才是具体的传值参数。 这段Json用商户号对应的MD5种子

加密，主要也省去了每个参数客户端单独加密，服务端又单独解密的繁琐。

与此同时，我们还需要上送客户端的硬件id，会用的信息，商户信息等。主要就在服务端能做更细致的控制。

差不多就说道这里吧，有兴趣一起探讨Winner框架的可以加我们QQ群：261083244。或者扫描左侧二维码加群。