接口中心四大闭环：如何确保接口生命周期的完美呈现

世间万物的存在都是有一个时限的，接口也不例外。通过建设接口中心，能否把接口的整个生命周期以数字化的方式呈现出来，这是这篇文章希望表达的内容。        

接口中心的建设要考虑以下四个场景的闭环。

首先是接口定义的闭环，也就是接口定义和代码实现之间的一致性问题。

其次是接口验证的闭环，从接口调试、接口测试的角度对接口定义进行验证和反馈。

第三是线下线上的闭环，接口中心结合线上可观测、调用链等接口运行数据对接口设计进行反馈。

第四是上线、下线的闭环，也就是接口生命周期管理和版本管理。

而三个核心分体分别是

第一，接口信源在哪里？哪里是第一现场

第二，接口定义采用哪个OpenAPI版本的协议？

第三，接口的版本如何管理。

首先来讲一下关于四个场景的闭环。

接口定义 

接口平台实现接口全生命周期的闭环管理，首先第一条就是接口定义的闭环。也就是说你的接口定义准不准？和代码的实现保存保持一致吗？通常定义的时候是准的。那么随着接口的改动。还持续能保持一致吗？。   

要回答这个问题，笔者认为需要关注接口定义的第一责任人。

以自身内部的建设经历来讲，在接口中心的建设初期，我们内部曾有过几次大的争论，也就是接口中心关于接口的定义的信源，也就是接口定义第一现场到底在哪里的问题。那么分成了两大观点，一个观点是参考现有诸多接口平台领域的创业公司所发布的接口平台为案例，认为应该以接口平台作为接口定义的源头。而我们通过走访调研前期的接口平台用户，发现绝大部分种子用户，即使是所谓以接口平台作为源头，也是由开发人员在IDE中先编写空的接口定义方法，然后再通过IDE插件的方式，传递到接口平台。即使后续接接口定义发生了变化，也是以习惯以这种方式来上传更新。我们称这两种为所谓的产品经理驱动和(后端)开发驱动的接口定义模式。

在我们的场景中，通过调研分析，现阶段和一段时间内，还是以开发驱动的模式为主。因此我们选择了以IDE为第一现场，以后端代码为信源，通过接口注解在CI环节的自动向接口平台申报来实现接口定义。由此，开发了IDE插件来实现接口注解的自动生成、校验的并在DevOps平台中结合流水线进行接口申报和差异比对等能力。

如果是所谓的产品经理驱动的模式，笔者认为也需要考虑设计接口代码与接口平台中对应接口定义的比对、稽核的功能，并能形成卡点，以保障接口定义的持续准确性。

接口验证的闭环  

第二个闭环比较容易理解，也就是接口自动化测试平台和接口平台的整合，进而实现接口验证的闭环。读者如果去考察一下市场上主流的接口平台或者接口自动化测试平台的话，可以发现两者已经趋于融合。无论这些厂商的出发点在哪里，目前都能提供这两块能力了。

笔者认为，实现两者整合的一个典型功能是，在编写接口自动化测试时，可以直接引用来自接口中心的各个接口，而不再直接使用原生HTTP请求来描述。如下图为某个接口自动化平台的图示，

这样对于用户编写编排接口自动化测试用例来讲，具备了更高的易用性。而对于接口自动化测试的结果来讲，那么也更容易从接口覆盖率等角度来进行评估。而从接口中心的视角，也能快速浏览针对该接口的测试用例甚至是缺陷的质量保障的信息，为接口的正确设计提供了验证和反馈。  

线上线下的闭环   

第三个是接口中心和线上可观测体系进行整合，实现线上线下的闭环。接口中心通常被认为主要是一个接口定义的权威数据源，主要服务于开发和测试人员。而运维侧的可观测体系中，有着接口在线上运行时丰富数据。通过两者的有效整合，能让研发人员更方便地在接口中心了解到负责接口的线上的使用情况，如调用/被调用的接口、接口冷热、忙闲以及接口性能、容量和报错等一系列的宝贵信息，实现一个接口设计和接口运行的反馈闭环，为接口的有效治理提供基础保障。

上线下线的闭环  

前面讲到了线上线下的问题，这里再提一下接口上线下线的问题。世间万物的存在都是有一个时限的，接口也不例外。一个接口的生命也是有限的。而通过接口中心与DevOps的整合，在持续集成、应用发布、上线等环节获取接口的相关数据，形成接口从定义、开发、发布、上线，期间不断变更，直至最后下线的一整个生命周期的过程也就是实现所谓的接口生命管理。

这其中也涉及到所谓的接口版本管理。那么我们要需要定义什么叫接口的变更以及它的版本，并且团队也需要明确接口版本的展展现方式，是采用不同URL进行接口版本管理，还是直接在原先的接口上进行接口定义的变更，并通过某种方式通知到下游的使用方。这是团队和组织在开发规范中需要考虑的一个问题。   

三个核心问题

从上面关于四个闭环的描述中，我么你可以提取到三个核心问题。分别是

第一，接口定义的信源在哪里？也就是哪里才是接口定义的第一现场。这是一个关于人的职责划分的问题，不仅仅是一个技术问题。

第二，接口定义采用哪个OpenAPI版本的协议？这个问题读者需要了解到OpenAPI的V2/V3版本之间的差异，包括协议schema的差异以及对应生成和获取接口文件方式的差异。无论第一个问题的答案是什么，都涉及到接口定义和实现之间如何持续保持一致性的问题，所以这是一个必须要回答的问题。

第三，接口的版本如何管理。如前所述，这也是一个编码规范的问题。如果已经先于接口平台的建设之前就已经有规范，则接口平台遵循即可。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：【文末自行领取】

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！