关于java:淘宝-开放平台接口设计思路

57次阅读

共计 2736 个字符,预计需要花费 7 分钟才能阅读完成。

最近对接的开放平台有点多,像淘宝、京东、快手、抖音等电商平台的开放平台根本对接了个遍,什么是 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 程序员,目前正在筹备出道的路上。。。,记得给我点个赞,激励激励!

正文完
 0