您的位置
主页 > 国际新闻 » 正文

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

来源:www.liberte484.com 点击:1649

2019-09-10 20: 32: 24每个人都是产品经理

紧随文章《4个要点,编写一份接口需求文档》之后,本文分析了工作中已完成的示例,并希望这些示例可以对接口设计中需要考虑的因素有更深入的了解。

情况1

1.需求背景

SRM系统的用户需要检查自己在SRM中提供的产品的质量检查;但是,质量检验数据位于商品管理系统中,因此需要SRM从商品管理系统中获取相应的数据

2.需求设计

需求的关键点是SRM需要从商品管理系统获取数据并将其提供给自己的用户。有两种方法可以实现此目的:

(1)从商品管理系统获得SRM固定频率

选择这种方式存在一个无法避免的问题:什么时候获取数据合适?一般性认为固定频率,那么该频率应该是多少?

考虑到用户会随时单击查看,因此半小时一小时的频率绝对不会起作用;实时性能越高,半分钟还是一分钟更好?

与半小时相比,实时性能要高得多。但是,考虑到数据量,尽管每分钟都会获取一次,但是在获取数据并进行合法性验证和程序集存储之后,整个周期远远少于1分钟。当用户单击时,可能只是获取了数据,并且尚未对其进行处理并将其存储在表中,因此无法显示该数据;

同时,在这种情况下,随着数据量的增加,容易泄漏数据和复制数据。数据量太大,程序的执行时间太长,并且会自动停止,从而导致数据丢失,并且第一次没有被处理。第二次已经开始,并且相同的数据被多次写入,从而导致数据重复。

因此,这种方法是不可行的。

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

既然不可能自己拿,那么主动与srm同步数据的商品管理系统呢?

当商品管理系统的质检信息发生变化时,主动将数据同步到srm。当用户在srm中查看数据时,srm从自己的表中获取数据并显示它们。这样,该方案完全可以满足要求。

当我开始这样做的时候,我也选择了这个解决方案,但是当我与开发人员交流时(通常界面更面向技术,所以我会私下与开发人员讨论),我发现一个问题:是否有必要在两个系统中存储同一信息的两个副本?由于质检信息中有附件文件,文件占用了大量的存储空间。有没有更好的方法来避免这种缺陷?

结合以上两个分析,我们知道这个界面有两个要点:

实时性要求很高,如果能共享一条信息,就不会保存两份。

由于实时性要求很高,为什么不去商品管理系统获取数据,并在用户查看时实时显示出来呢?这也解决了srm不需要存储冗余信息的问题。

为此,最好的解决方案是:当用户点击SRM时,SRM进入商品管理系统获取质量检验信息并实时显示,无需本地存储:

0x251D

PS:实时获取存在一个看不见的问题:并发性。如果并发性很高,则不建议采用实时采集的方式。但在这种业务中,并发的可能性很低,因此该方案是可行的和最优的。

病例2

1。需求背景

采购系统需要对同步产品的未成功订单数量进行预测,以便于对后期的服务采购量进行预测;采购量的预测每天一次,从清晨开始。

2.需求设计

由于购买金额是每天计算一次,因此可以在计算之前进行数据同步,对实时性的要求不高。由于整个预测过程都需要大量计算,因此预测系统必须存储要计算的数据,并且无法计算数据。而不是文件数据,占用较小的存储空间,因此必须存储此数据预测系统;由于预测服务需要完整的数据量,因此无需将参数与参数一起获取数据。

因此,界面可以设计如下:

从表面上看,这种界面设计没有问题,完全令人满意。

但是,一个被忽略的问题是,由于双方没有明确同意更新数据的方式,因此双方都没有错误。

显然,同步侧会完全同步数据,但是接收器会增量更新数据。

当产品前一天的计划外编号为34时,该编号在第二天更新为0,则接收方不会将34更新为0,而是仍然保存34。

情况3

1.需求背景

客户服务系统需要根据客户的需求,从产品供应商那里获取产品操作指南等辅助信息;由于客户服务系统没有供应商信息,因此需要从SRM系统获取供应商信息;停止合作的供应商应排除在外;企业需要产品对应。

2.需求设计

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

这种设计的一个大问题是供应商的州客户服务系统没有这样做。如果提前实施,则由双方根据现有状态值达成一致。然而,随着SRM系统的发展,当改变或增加供应商的状态值时,在双方的数据上都有隐患,并且无法获得数据。设计不能不说容错能力很低。

(2)由于客户服务系统没有状态值,因此只能根据产品代码获得。我不会将供应商及其状态退还给它。因此,我的第二个版本设计是这样的:

实际上,该设计与第一个版本存在相同的问题。即使返回到状态,因为它不知道这些状态的业务含义,因此它也不能筛选出无用的数据,而只能向客户服务人员显示有效信息。

(3)经过两个版本,我的第三版设计如下:

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

(4)结合以上内容,最终设计如下:

情况4

1.需求背景

需求生成服务需要告知采购系统的采购需求,以根据采购系统做出采购订单;采购系统对数据的要求因情况而异。在此假定类别A需求必须具有字段a,而类别B需求则不需要字段a。

2.需求设计

当我开始设计文档时,我将其设计用于验证:

当类A需求没有字段a时,它返回错误消息“需求字段a不能为空”;当B类需求具有字段a时,它将返回错误消息“ B需求字段a应该为空”。

在与开发进行沟通的过程中,他们提出了一个问题:如果对字段a给出了B类的要求,是否会影响以下过程?

我的回答是:否,但是不需要此信息背后的过程。

然后,当将B类要求提供给字段a时,通常会收到数据,但不会收到字段a。

这样做的好处是,接口验证的层更少,更轻,更简单。它不会因信息不可用而影响后面的过程。

因此,更改检查逻辑:

当类A需求没有字段a时,它将返回错误消息“需求字段a不能为空”。当B类需求具有字段a时,它不接收字段a,但通常接收所需的其他字段。

这涉及接口设计中的验证。添加验证的目的是确保彼此通信的数据正确。对于接收者,由于错误,他接收的信息不是垃圾数据或影响后续过程。

但是,在设计验证规则时,应更适当地考虑强或弱验证。与上面的界面一样,类别A要求的字段a是以下过程中必须使用的信息,因此必须使用严格的检查;相反,可以在B类中使用弱检查。

PS:诚然,除了这些问题外,还有一些要点,例如传输,分页,最大限制等。最好的方法是在明确业务需求后及时与发展学生讨论和交流,并听取他们的意见和考虑(因此,彼此相处非常重要,哈哈)。

#专栏作家#

水果,每个人都是产品经理专栏作家。擅长以业务为导向的产品设计以及业务流程和复杂问题的分解,希望找到产品工作的操作准则和方法论,并不断建立自己的知识体系

本文最初发布在每个人的产品经理上。未经许可禁止复制

该地图来自Unsplash,基于CC0协议

紧随文章《4个要点,编写一份接口需求文档》之后,本文分析了工作中已完成的示例,并希望这些示例可以对接口设计中需要考虑的因素有更深入的了解。

情况1

1.需求背景

SRM系统的用户需要检查自己在SRM中提供的产品的质量检查;但是,质量检验数据位于商品管理系统中,因此需要SRM从商品管理系统中获取相应的数据

2.需求设计

需求的关键点是SRM需要从商品管理系统获取数据并将其提供给自己的用户。有两种方法可以实现此目的:

(1)从商品管理系统获得SRM固定频率

选择这种方式存在一个无法避免的问题:什么时候获取数据合适?一般性认为固定频率,那么该频率应该是多少?

考虑到用户会随时单击查看,因此半小时一小时的频率绝对不会起作用;实时性能越高,半分钟还是一分钟更好?

与半小时相比,实时性能要高得多。但是,考虑到数据量,尽管每分钟都会获取一次,但是在获取数据并进行合法性验证和程序集存储之后,整个周期远远少于1分钟。当用户单击时,可能只是获取了数据,并且尚未对其进行处理并将其存储在表中,因此无法显示该数据;

同时,在这种情况下,随着数据量的增加,容易泄漏数据和复制数据。数据量太大,程序的执行时间太长,并且会自动停止,从而导致数据丢失,并且第一次没有被处理。第二次已经开始,并且相同的数据被多次写入,从而导致数据重复。

因此,该方法不可行。

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

由于不可行,商品管理系统是否主动将数据同步到SRM?

当商品管理系统的质量检查信息发生更改时,数据将主动同步到SRM。当用户查看SRM时,SRM将从自己的表中获取数据并显示出来,从而使该方案可以完全满足要求。

当我开始这样做时,我也选择了这种解决方案,但是当我与开发人员进行通信时(通常,该接口是技术性更高的,因此我将事先与开发人员私下讨论),然后发现存在问题:具有相同的信息是否有必要在两个系统中存储两个副本?由于质量检查信息中包含附件文件,因此文件会占用大量存储空间。是否有更好的解决方案来避免此缺陷?

结合以上两个分析,我们知道该界面有两点:

实时性要求极高;单份信息没有两份副本。

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

满足此需求的最佳解决方案是:当用户单击SRM时,SRM进入商品管理系统以获取质量检查信息并实时显示,而无需本地保存:

PS:实时获取存在一个看不见的问题:并发。如果并发量很高,则不希望采用实时获取的方式。但是,在该业务中,并发的可能性很小,因此该方案是可行且最佳的。

情况2

1.需求背景

采购系统需要预测同步产品的不成功订单数量,以便于在服务预测的后半部分预测购买;每天早上从一天开始预测购买量。

2.需求设计

由于购买金额是每天计算一次,因此可以在计算之前进行数据同步,对实时性的要求不高。由于整个预测过程都需要大量计算,因此预测系统必须存储要计算的数据,并且无法计算数据。而不是文件数据,占用较小的存储空间,因此必须存储此数据预测系统;由于预测服务需要完整的数据量,因此无需将参数与参数一起获取数据。

因此,界面可以设计如下:

从表面上看,这种界面设计没有问题,完全令人满意。

但是,一个被忽略的问题是,由于双方没有明确同意更新数据的方式,因此双方都没有错误。

显然,同步侧会完全同步数据,但是接收器会增量更新数据。

当产品前一天的计划外编号为34时,该编号在第二天更新为0,则接收方不会将34更新为0,而是仍然保存34。

情况3

1.需求背景

客户服务系统需要根据客户的需求,从产品供应商那里获取产品操作指南等辅助信息;由于客户服务系统没有供应商信息,因此需要从SRM系统获取供应商信息;停止合作的供应商应排除在外;企业需要产品对应。

2.需求设计

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

这种设计的一个大问题是供应商的州客户服务系统没有这样做。如果提前实施,则由双方根据现有状态值达成一致。然而,随着SRM系统的发展,当改变或增加供应商的状态值时,在双方的数据上都有隐患,并且无法获得数据。设计不能不说容错能力很低。

(2)由于客户服务系统没有状态值,因此只能根据产品代码获得。我不会将供应商及其状态退还给它。因此,我的第二个版本设计是这样的:

实际上,该设计与第一个版本存在相同的问题。即使返回到状态,因为它不知道这些状态的业务含义,因此它也不能筛选出无用的数据,而只能向客户服务人员显示有效信息。

(3)经过两个版本,我的第三版设计如下:

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

(4)结合以上内容,最终设计如下:

情况4

1.需求背景

需求生成服务需要告知采购系统的采购需求,以根据采购系统做出采购订单;采购系统对数据的要求因情况而异。在此假定类别A需求必须具有字段a,而类别B需求则不需要字段a。

2.需求设计

当我开始设计文档时,我将其设计用于验证:

当A类需求没有字段a时,返回错误消息“需求字段a不能为空”;当B类需求具有字段a时,将返回错误消息“ B需求字段a应该为空”。

在与开发人员进行沟通的过程中,他们提出了建议:如果B类要求给字段a,是否会影响后续过程?

我的回答是:不,只是该过程以后不再使用。

然后,当对字段a给出B类要求时,通常接收数据,但是不接收字段a。

这样做的好处是接口验证少一层,并且变得更轻便,更简单。由于未使用的信息,它不会影响后续过程。

因此,更改检查逻辑:

当A类需求没有字段a时,返回错误消息“需求字段a不能为空”;当B类需求具有字段a时,不接收该字段a,但是正常接收正常接收所需的其他字段。

这涉及接口设计中的验证。添加验证的目的是确保彼此通信的数据正确。保证接收方接收到的信息不是垃圾数据,否则后续过程将受到错误的影响。

但是,在设计验证规则时,应该进行更强或更弱的检查。与上述接口一样,类别A要求的字段a是在后续过程中必须使用的信息,因此必须使用严格的检查;相反,B类使用弱检查。

PS:确实,除了这些问题外,还有一些主要的细节传输、分页、最大限制等方面的问题,最好的办法是在了解业务需求后及时与开发学生讨论和沟通。他们的意见和考虑(所以保持良好的关系很重要,哈哈)。

#柱工作者

水果,每个人都是产品经理专栏作家。擅长面向业务的产品设计,以及业务流程的流程和复杂问题的分解,希望能为产品工作找到操作指南和方法论,并不断构建自己的知识体系

这篇文章最初发表在每个人的产品经理上。未经允许,禁止复制

映射来自unsplash,基于cc0协议



最新要闻