《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。或者扫描左侧二维码加群。