2

“淘宝” 开放平台接口设计思路

 2 years ago
source link: https://segmentfault.com/a/1190000040734435
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

最近对接的开放平台有点多,像淘宝、京东、快手、抖音等电商平台的开放平台基本对接了个遍,什么是CRUD BODY也许就是这样的吧!!!

虽然对接各大开放平台没啥技术含量,但咱也得学点东西不是,不能白对接哈!经过这几天的整理,脑子里大概有了个开放平台接口的设计套路,故整理成文章方便有需要的时间去实现自己的开放平台接口。

开放平台比较关注的几个点:

  • 易用性:接口设计要简洁,请求参数要见名知意,使服务商能快速接收,为用户提供服务
  • 安全性:开放平台接口是暴露在外网,必须保证用户数据的安全
  • 稳定性:开放平台接口是给上游的服务商使用,必须保证稳定为服务商应用提供服务

服务商应用

开放平台可以分为几大部分:

  1. 接入指南:帮助服务商接入开放平台
  2. 接口文档:帮助服务商的开发人员,实现业务功能
  3. 应用:服务商应用在开放平台的身份标示

服务商接入开放平台的首要步骤就是创建应用,有了服务商应用平台内部就能辨别服务商的身份,这样就能很方便的做限流、权限控制等。

服务商应用一般有appid、appsecret、授权回调地址这三个基本的属性:

  • appid: 服务商应用的唯一标识
  • appsecret:服务商应用的密钥签名、验证身份时用到
  • 授权回调地址:授权时会用到

授权不是开放平台对服务商应用的授权 ,而是需要开放平台的客户(用户)对服务商应用的授予,比如ERP应用,也就是淘宝的店铺商家对应用进行授权,使其能够拉取到店铺的订单来完成订单履约。

淘宝授权页

所以授权需要三个角色才能完成:

    • 提供授权页面,引导客户完成服务商应用的授权
    • 客户完成授权后,跳转到服务商应用提供的授权回调地址同时带上授权信息
  • 客户:在开放平台提供的授权页面中,完成对服务商应用的授权
  • 服务商应用:接收开放平台回调的授权信息,完成务商应用与客户的绑定关系、保存授权信息

当然也可以使用appid + appsecret 直接认证服务商应用的身份,这种适合没有第三方的时候,数据都是属于开放平台的,跟客户没有半点关系,也就不存在需要客户授权的问题。

OAuth2授权机制

OAuth2是一套授权标准,现在互联网做授权基本都用它,如github登陆 、微信公众号授权等都是基于OAuth2的应用。

如果不了解OAuth2可以参考我以前的文章:

[一文带你了解 OAuth2 协议与 Spring Security OAuth2 集成!
](https://mp.weixin.qq.com/s?__...;mid=2247488722&idx=1&sn=9d0ec7d5b9a16611073eb31d07afd99e&chksm=9f47781aa830f10c3e6baefc6ebba7501183dba8f65f810ee3d748c85b75b57ab6279c340b7d&token=1300302581&lang=zh_CN#rd)

授权流程

请求参数分两类:系统参数业务参数

  • 系统参数:每次API调用都必需携带的参数
  • 业务参数:开放平台根据不同的业务,提供的参数。

业务参数根据业务来定,先说系统参数一般包含:

  • appid:服务商应用唯一标识
  • appsecret: 服务商应用密钥
  • timestamp:时间戳
  • sign:请求签名

系统参数使用url参数传递

业务参数是调用开放平台接口时传递的请求参数,如一次订单查询接口,要实现按订单状态的维度查询订单,那么订单查询接口就需要接收status参数,然后去查库后返回订单数据。

业务参数的载体,常用的如:application/jsonapplication/x-www-form-urlencode等。

业务参数使用post请求参数的方式传递,同时也需要参与签名,后面说签名会提到

对请求签名的目的就是防止数据被篡改,常见的md5sha都可以用来做为签名算法,理论上只要保证双方能够生成签名和验签就行,像支付宝这类高安全级别的应用就是使用的非对称加密,双方各生成一对私钥和公钥,然后交换公钥用于验签即可。

生成签名的方式自行定义,这里列举一个常见的签名生成方式:

sign = appsecret + appid + timestamp + 业务参数(排序后) + appsecret

伪代码

String appid = "abcd";
String appsecret = "12345";
Long timestamp = 948758686
//有序map,按key的值排序
Map<String, Object> requestBody = new TreeMap<>();
requestBody.put("a", 1);
requestBody.put("b",21);
requestBody.put("c", 2);
//转换成json字符串
String jsonBody = JSON.toJSONString(requestBody);
String sign  = DigestUtils.md5hex(appsecret + appid + timestamp + jsonBody + appsecret);

验签步骤与生成签名的步骤类似,仿代码如下:

String appid = request.getParameter("appid");
String appsecret = request.getParameter("appsecret");
Long timestamp = request.getParameter("timestamp");
//拿出请求的业务参数,转成TreeMap
Map<String, Object> requestBody = new TreeMap<>(JSON.parseObject("post请求参数"));
//转换成json字符串
String jsonBody = JSON.toJSONString(requestBody);
String sign  = DigestUtils.md5hex(appsecret + appid + timestamp + jsonBody + appsecret);
String originSign =  request.getParameter("sign");
if(Objects.equals(sign ,originSign )){
  //验证签名成功
}else{
  //验证签名失败
}

以上就是开放平台接口设计的一些思路,其实也是对接开放平台多了, 对那些开放平台对接的一些基本的套路的一些整理,希望有朝一日能用上。

对接开放平台的时候遇到的问题不少,有的平台有SDK有的是直接是restapi,有SDK的平台对接起来还是挺幸福的,下期给大家整个平台SDK的设计。

在下艺名惊天霸戈(惊天bug),一枚喜欢制造bug的Java程序员,目前正在准备出道的路上。。。,记得给我点个赞,鼓励鼓励!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK