澳门百乐门娱乐场_新浪财经

百乐门娱乐场4个真实案例看接口文档的设计要点

时间:2020-09-01 17:08

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

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

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

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

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

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

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

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

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

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

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

  采购系统需要给预测服务同步产品的未成功订货的数量,以方便预测服务预测后期的采购量;

  因为采购量每天算一次,所以在计算前将数据同步过去即可,实时性要求不高;

  因为整个预测过程需要大量的计算,预测系统必须存储数据方便计算,不可能计算到的时候再来取数据,并且不是文件数据,占用存储空间小,所以此数据预测系统必须存储;

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

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

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

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

  (2)既然客服系统没有状态值,那它只根据商品编码来获取,我将供应商及其状态都返回给它不就可以了,为此我的第二版设计是这样的:

  这样的设计其实跟第一版有同样的问题,即使将状态返回给它,它因为不知道这些状态的业务意义,也就无法过滤掉那些没用的数据只给客服人员展示有效的信息。

  此次的设计解决了前两次的问题,但是没有考虑异常情况:没有满足条件的数据时,要返回什么来告诉对方为什么没有数据?所以接口还需要一个错误信息。

  在与开发沟通的过程中,他们提出:如果B类需求给了字段a,会不会影响后面的流程?

  这样做的好处是:接口校验少了一层,变得更轻更简单;不会因为一个用不到的信息影响后面的流程。

  这里涉及到接口设计中的校验,增加校验的目的是,保证相互通讯的数据是正确的,对接收方而言保证自己受到的信息不是垃圾数据或因为错误而影响后面流程。

  但是在设计校验规则时,应该有一个强校验还是弱校验更合适的考量。正如上文的接口,A类需求的字段a是后面流程必须用到的信息,所以必须采用强校验;相反B类采用弱校验即可。

  PS:诚然,除了这些问题以外,还有主明细方式传输、分页、最大量限制等等的点,最好的方式是在搞清楚业务需求后,及时跟开发同学做下探讨和沟通,听听他们的意见和考量(所以处好关系很重要呀,哈哈)。

  果果,人人都是产品经理专栏作家。擅长业务导向性的产品设计,以及对业务流程的梳理和复杂问题的拆解,希望能找到产品工作的操作指南和方法论,不断搭建自己的知识体系

  为啥我看了两遍,还是觉得第三点和第一二亮点的表格应该换一下呢,既然是返回商品编码和状态,为啥第三个方案没有返回参数‘商品状态’了呢,而是增加了一个验证“只返回符合状态的供应商”,这点也不太理解,既然对方没有状态的字段,不应该根据商品编码返回供应商吗

  对方需求的信息是满足某些条件的商家;返回状态对它没有意义,因为状态的定义在你这边,你告诉他A商家是这个状态,B商家是那个状态,它听不懂的,因为他不知道你定义的状态的含义,因此他就没法根据需要过滤。这点在文章中相应的方案下面解释了。

  恩,打错了,是供应商状态;其实是不太理解既然说要返回状态给对方,后面的优化方案把返回状态参数给删了,而是在返回编码里写了“只返回符合状态的供应商”,既然对方没有状态的字段,又是如何根据状态来筛选呢?没有返回状态参数,又是在哪里返回呢?我是小白,多谢指教

  那么考虑到有效触达,我们就要考虑这个信息的接收供应商账号是正常的非冻结的

  那么什么状态标识账号是冻结的、还是正常的,这个信息是在供应商基础数据管理这边定义的,客服系统肯定不知道

  这样的话,如果我给它状态,它没法筛选,因为它不知道哪些状态值标识账号是正常的(比如我这里有三个状态 ,分别用1 2 3 标识,当我告诉它一些供应商是1 一些是2 客服系统不知道1 2 是啥意思;并且如果我把所有状态的供应商都给它,后期如果我这边的状态新增了,那么它那边也要新增这个值,这样子扩展性很低)

  鉴于此,为什么我不知道过滤好,告诉它最终结果就好了:我给你的供应商就是有效的,你只要把信息触发给这些供应商就好了

  这样子对客服系统的业务是最轻量级的;对我这边来说,后期我状态怎么扩展,也只要在我这边改动逻辑即可

  不管接口怎么设计,业务上的字段和校验一定是要有的;很多细节在开发过程中可以相互讨论来补充和优化

  你好,请问下从其他系统同步数据,让产品给方案。这个方案一般指的是什么?在我理解中不是需求吧

  目前对于实时性要求不高的可以用消息订阅方式进行数据通知,然后通过接口更新同步,这样数据是存两份;另一种就是服务接口,用WEBSERVICE或HESSIAN等协议都可以,为了提高速度还可以加缓存