炼金术: 怎样做好1个业务流程的接口对接

Posted math

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了炼金术: 怎样做好1个业务流程的接口对接相关的知识,希望对你有一定的参考价值。

假设一个完整的项目,包含了6个不同的【端】:PC客户端、移动端、官网、支付页面、活动页面、以及后端、以及底层的核心功能组件开发。

假设有5个人分别负责5个【有脸】的【端】:PC客户端、移动端、官网、支付页面、活动页面;假设1个人负责开发后端,实际多少人不知道,这1个人是一个代表;假设2个人负责开发底层核心功能组件,实际多少人不知道,这2个人是一个代表;假设1个跟进的测试。

假设产品上,做好了MVP功能分析和设计,写了每个端的设计文档。此时产品【不能】直接把文档给每个端的负责人后,就等待着每个端的人做开发。此时需要做【需求确认】:跟每个端的负责人【正式】的开一个讨论,【逐条】核对设计,确认彼此对这个端需求的第一次【共识】。如果【没有】这一个必要的讨论,设计只存在于产品自己的脑子里。其他人可能会只看个大概,就开始写代码而已开始就留下和第1版需求不匹配的问题。

在开发中,不同的端会先从不依赖其他端的功能开始实现,涉及到需要和其他端对接的接口时。就一定要停下手里的工作,【优先】做【接口确认】:找其他端的负责人确认一个业务模型的接口设计,此时不应该只考虑这两个端之间,而应该能从整体构架上考虑,多个端之间的接口之间,应该有一个时序图,这个时序图展示了一条完整的业务流程:

  1. 从哪些入口开始发起业务,假设在A端,调用了入口startXXX。
  2. 从入口开始考虑完整的接口调用【闭环】:
    • 依赖了其他端的哪些接口,比如像后端调用1个或N个接口。
    • 监听了其他端的哪些事件,比如监听了后端的1个或N个事件。
    • 过程中是否跳转到了其他端,例如显示一个二维码,扫码后跳转到了网页,在网页那边做了什么处理,例如调用了后端接口,后端接口又触发了事件给A端。

经过这个讨论,每个端确认了自己这端的逻辑在1个业务流程中的【位置】和作用,同时对流程的全局有清晰的认识。

在理解这条业务流程后,达成了共识,但是还不够。在构架上,这些分散的流程点,应该被封装在一个公共组件中,每个端都依赖这个公共组件的接口和事件。假设该组件是C,那么:

  1. C应该提供一组【满足不同需求的入口】接口,以便满足不同端的不同场景入口调用需求。
  2. C应该提供一套标准的事件,不同的入口都应该触发后续【一致的事件流】。使得每个端针对同一个业务要关心的事件流是一致的。
  3. C应该把细节隐藏在内部,在内部做好【完整的状态机】,以及做好完整的错误处理、超时处理、重试机制等等。

应该针对这一条业务流程,以这个公共组件为入口,写【基于命令行】的【情景测试】代码。经过基本测试可用后,才提交接口实现,并通知其他端接口和组件可用。

从覆盖率上考虑,应该针对每个独立的接口,编写针对接口的单元测试。包含正常的数据和不正常的数据的测试和断言等。可以由开发人员编写,或者【分工】给有编写单元测试代码能力的测试编写。

到这里,针对1个业务流程,形成涉及多端的设计、对接、封装、测试的【闭环】,而不致于变成每个端都一知半解的【玩具接口对接】。在多次迭代中,会持续对这个链条做调整,逐步完成对链条的完整认识。程序开发环境一直在分裂,客户端多多样化,后端的分布式化,开发环境在【裂化】,做好1个业务流程的接口设计和对接,需要有整体的闭环,以规避程序开发中“不识庐山真面目,只缘身在此山中”问题。

--end--

以上是关于炼金术: 怎样做好1个业务流程的接口对接的主要内容,如果未能解决你的问题,请参考以下文章

上传文件流程对接

如何调用第三方电子签章接口

对接新通道的分析处理

python+pytest接口自动化-接口测试一般流程及方法

python+pytest接口自动化-接口测试一般流程及方法

顺丰电子面单api接口怎么接入?