幸运分分彩 首页 > 学霸

4个真实案例,看接口文档的设计要点

2019-09-10 22:17 weila

接上一篇文章《4个要点,编写一份接口需求文档》,本文对工作中做过的实例进行分析,希望通过实例能对接口设计需要考虑的因素有更深的理解。

接上一篇文章《4个要点,编写一份接口需求文档》,本文对工作中做过的实例进行分析,希望通过实例能对接口设计需要考虑的因素有更深的理解。

案例1 1. 需求背景

需求关键点是SRM需要从商品管理系统获取数据并展示给五分PK10用户,实现这一点有两种方式:

(1)SRM固定频次从商品管理系统获取

选择这种方式,有一个绕不开的问题:什么时候去取数据合适?普遍的自然就想到按固定的频率,那么这个频率应该是什么?

考虑到用户随时都会点击查看,半小时、一小时的频率肯定不行;实时性应该越高越好,那半分钟或者1分钟取一次呢?

这样做相比半小时实时性高了很多,但考虑到数据量的因素,虽然每分钟会去获取,但是获取到数据后进行合法性校验、完了组装存储,整个周期就远不是1分钟了,有可能用户点击的时候,数据刚获取到,还没处理完存储到表中,故也无法展示;

同时,随着数据量增大,此种情况下很容易出现漏数据和数据重复的情况,数据量太大,程序执行时间过长而自动停止,导致数据遗漏,第一次还没处理完,第二次已经开始了,结果相同的数据多次写入,导致数据重复。

故此种方式不可行。

(2)商品管理系统主动同步

既然五分PK10取不可行,那么商品管理系统主动将数据同步到SRM呢?

当商品管理系统的质检信息有变更时,主动将数据同步给SRM,用户在SRM查看的时候,SRM从五分PK10的表中获取数据并展示,这样看这种方案是完全能够满足要求的。

展开全文

我一开始做的时候,也是选择的这种方案,但是在与开发沟通的时候(一般做接口更偏向技术,所以我都事先会跟开发私下讨论一下),发现有一个问题:相同的信息有没有必要在两个系统存储两份?因为质检信息中存在附件文件,文件很占存储空间。是否有更好的方案来避免这个缺陷?

结合上面这两个分析,我们知道这个接口有两个点很重要:

基于实时性要求高这个点,为什么不做成用户查看的时候,实时去商品管理系统获取数据并展示出来呢?这样也解决了SRM不用存储冗余信息的问题。

为此此需求最佳的方案是:当用户在SRM点击查看的时候,SRM实时去商品管理系统获取质检信息并展示,无需本地保存:

PS:实时获取有一个隐形的问题是:并发。若并发量高,实时获取的方式不可取。但此业务中,并发可能性低,所以此方案可行最优。

案例2 1. 需求背景

因此接口可设计如下:

从表面上看,这个接口设计没有问题,完全满足需要。

但是忽略的一个问题是:因为双方没有明确约定数据更新方式,导致两边数据对不上出了bug。

很明显,同步方是以全量的方式同步数据的,但是接收方在接收数据的时候,却是以增量的方式更新的。

当一个产品前一天同步的未订数量是34,第二天这个数量更新成了0的时候,接收方没有将34更新成0,存的还是34。

案例3 1. 需求背景

(1)考虑到客服系统对状态有要求,为了更加灵活,我将接口设计如下:

这样的设计有个很大的问题是,供应商的状态客服系统并没有。假如在预先实现时,根据现有状态值双方约定好,但随着SRM系统的发展,当供应商的状态值变更或新增时,存在两边数据不一致和获取不到数据的隐患,所以这样的设计不能不说容错性是很低的。