从微信支付宝支付接口设计谈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的唠嗑节目。

唠嗑

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏BestSDK

Google发布Nearby Connections API 2.0版本,可拓展本地信息和数据分享

关注过 I/O 2017 开发者大会的网友们,或许还记得 Google 提到过的“情境应用体验”(Contextual App Experiences)。这组 ...

2944
来自专栏CSDN技术头条

Google的App引擎添加了对Node.js的支持

image.png JavaScript开发者现在可以使用Google的PaaS云服务来构建网页应用和移动端的服务了! Google宣布,将于Node.js的的...

2036
来自专栏13blog.site

Spring+SpringMVC+MyBatis+easyUI整合进阶篇(七)一次线上Mysql数据库崩溃事故的记录

作者:13 GitHub:https://github.com/ZHENFENG13 版权声明:本文为原创文章,未经允许不得转载。 文章简介 工作这几...

3374
来自专栏肖洒的博客

【爬虫】(五)数据存储之CSV

CSV( Comma-Separated Values,逗号分隔值)是存储表格数据的常用文件格式。

401
来自专栏Python爬虫与算法进阶

Android 7.0最新体验报告

在无数“加油”的殷切期盼下,一加终于在12月14号放出了基于Android 7.0的氢OS 3.0公测版,适用于一加3。那这“一加”牌的牛扎糖口味如何呢?新的氢...

4069
来自专栏WeTest质量开放平台团队的专栏

Android P专区免费开放 -- 同样的Android,不同的体验

原文链接:http://wetest.qq.com/lab/view/376.html

4713
来自专栏微信终端开发团队的专栏

基于TLS1.3的微信安全通信协议mmtls介绍

编者的话:近年来网络安全事件层出不穷,确保亿万用户的安全隐私是我们微信义不容辞的责任。当然,我们更要保证用户稳定、快速的聊天体验,所以我们有了mmtls。文章干...

60410
来自专栏CSDN技术头条

GoSnaps:如何支持5天50万用户服务器只花100元

创业者们似乎有这样一个共识:初创公司应尽快推出MVP(最简可行产品)而不应该把扩展性这样的细节放在心上。总是有人给我说推产品是最高的也实际上是唯一的目标,扩展性...

18510
来自专栏BestSDK

简单5步使用即构SDK,实现在线抓娃娃H5产品

为了保障即构线上抓娃娃H5方案能够普遍的适配所有浏览器,即构团队在视频网络完成视频转码,把视频转成MPEG1。然后,在用户侧H5和视频网络之间加入接入服务器,把...

3836
来自专栏企鹅号快讯

简单5步使用即构SDK,实现在线抓娃娃H5产品

为了保障即构线上抓娃娃H5方案能够普遍的适配所有浏览器,即构团队在视频网络完成视频转码,把视频转成MPEG1。然后,在用户侧H5和视频网络之间加入接入服务器,把...

2589

扫码关注云+社区