从微信支付宝支付接口设计谈API接口产品的设计经验和最佳实践

命令模式和RESTful的抉择

首先,我们查看微信的API,它使用的是类RESTful服务的实现,每个功能都有各自的URI。

微信API的示例如下。

下单:

https://api.mch.weixin.qq.com/pay/unifiedorder

查单:

https://api.mch.weixin.qq.com/pay/orderquery

可见,下单和查单的API具有相同的URI前缀:https://api.mch.weixin.qq.com/pay,各自的后缀为unifiedorder和orderquery。

然后,我们再来查看一下支付宝支付的API的设计,它使用的是命令模式,

所有的功能都使用同一个URI。

统一的URI:

https://openapi.alipay.com/gateway.do

在HTTP协议中,提供了一个方法参数:method,通过方法参数来传递具体使用的功能,不同的方法表示使用不同的操作。

下单:

alipay.trade.pay

查单:

alipay.trade.query

我们看到,支付宝使用命令模式,只提供了一个统一的URI,然后通过method参数来表示具体调用那个功能和操作。

对比微信支付的RESTful服务和支付宝支付的命令模式,各有优缺点。

两种方式的有点如下。

  • 对于命令模式,URI的设计比较简单,只需要设计统一的URI即可,具体选择哪个功能都在method中来表示,method参数易于扩展,扩展时不需要对URI和以及7层代理的URI路由进行修改,只需要对后端代码进行修改即可,对后期增加更多的命令和操作提供了方便。
  • 对于RESTful模式,每个功能和操作都有一个对应的URI,对于开发者来说学习起来比较简单,使用起来比较方便,URI信息是在HTTP头上进行传递的,由于URI的不同,在7层代理可以灵活配置分流和路由,这通常在迁移的过程中是需要的。

我们看到这两种方式各有优点,实际上,命令模式代表中心化的思想,而RESTful模式代表的是分而治之的思想,有的时候优点就是缺点儿,缺点就是优点,其实是个博弈。

命令模式是中心化的思想,比较封闭,虽然对将来的扩展实现比较容易,但是失去了简单易懂的优点。而RESTful是分而治之的思想,保持原汁原味的简单API的风格,看到URI就知道API的功能,简单易懂,方便使用。

这里,通过一个比喻来对比命令模式和RESTful模式,想象一下桌子上有3个杯子,杯子里面装着水、酒、雪碧,看起来都是透明的,如果每个杯子都没有标签,我们得拿起挨个尝一下,才知道哪个是水、酒或者雪碧,这就像命令模式一样,URI长得一样,想知道它是干什么的需要进一步看内部的参数,除了看起来麻烦,这在七层代理分流的时候,也是需要解析HTTP体才能看到method参数,性能偏低,然而,如果我们在杯子上加了标签,我们一眼就看出哪个是水、酒或者雪碧,这就像在7层代理需要分流的时候,直接在HTTP头中获取URI,做不同的事儿。

B2B API的安全策略

API接口属于典型的B2B的产品,对安全的要求比较特殊,需要验证企业的身份,这和用户端APP的安全技术栈不同,B2B的API产品通常通过签名和加密来保证安全。

要实施签名和加密安全策略,通常我们会进行抉择是用签名还是加密呢?用对称加密还是非对称加密?

这还是要从需求说起,安全需求也是需求的一种,我们总结安全需求无非这几种:

  1. 防篡改
  2. 防偷窥
  3. 防泄漏
  4. 防抵赖
  5. 防中间人攻击

要满足这些安全需求,我们采用不同的安全策略和方法,我们从密码学的历史开始说起,这一共经理了3个时代。

  1. 算法加密时代

    在很久以前,没有各种加密算法,为了防止软件被盗用,通常一般在软件中预留了一段加密算法,如果用户输入的注册码满足算法的需求,就通过了校验,这个时代叫做算法加密时代,以算法为核心来验证身份,但是这种方法有明显的缺陷,只要有足够强大的技术力量,算法都是可以被破解的。

  2. 对称加密时代

    这一时代,发明了对称加密算法,加解密方约定同一个秘钥,加密方用密匙加密,解密方用同一个密匙解密,如果可以成功解密,说明加解密方都有权限访问数据。对称加密有两个应用场景,一个就是签名,一个就是用来加密,对称加密和对称签名都是使用的对称加密算法,但是目的不一样,签名就想盖章一样,防止被篡改,而对称加密则是为了防止偷窥和防止泄漏。但是这一时代的对称加密算法也有个明显的缺点,就是加解密双方约定了同一个秘钥,加解密双方理论上都是可以抵赖的,如果秘钥泄露了,对可以说是对方泄露的,是无法判断是谁把秘钥泄露了。

    这一时代著名的算法有3DES、AES。

  3. 非对称加密时代

    到了非对称加密时代,解决了对称加密带来的抵赖问题,这一时代可以生成1对秘钥,1对秘钥由公钥和私钥组成,公钥加密数据只能有私钥来解密,私钥加密数据只能由公钥来解密,前者正式加密的应用场景,而后者是签名的应用场景。著名的SSL就是使用的非对称加密。

    这一时代著名的算法有RSA。

了解了这个背景,我们现在来回顾一开始我们提出的安全需求,要满足防篡改,只需要对称的签名即可,要满足防泄露和防偷窥,只要使用对称的加密即可,但是要满足防止抵赖,必须使用非对称签名和非对称加密。

但是要满足防止中间人攻击,那么,我们需要使用双向的非对称安全验证,通常使用双向的SSL来保证。

在支付行业里面的实践中,为了安全以及合规需求,我们通常需要使用非对称签名来保证数据不被篡改,使用非对称加密保证敏感数据不泄露,如果有出款需求,我们一般使用非对称的双向SSL证书来保证出款的安全。

阅读更多关于“从微信支付宝支付接口设计谈API接口产品的设计经验和最佳实践”的内容,请报名参加gitchat的唠嗑节目。

从微信支付宝支付接口设计谈API接口产品的设计经验和最佳实践_第1张图片
唠嗑

你可能感兴趣的:(从微信支付宝支付接口设计谈API接口产品的设计经验和最佳实践)