CN113971024A - 接口管理方法、装置、电子设备以及可读存储介质 - Google Patents

Abstract

本发明提供一种接口管理方法、装置、电子设备以及可读存储介质，方法包括：接收到后端开发者对同一接口文档的多个修改需求之后，将接口文档复制并保存多个，复制并保存后的接口文档的数量与修改需求的数量相等；将多个接口文档一一对应地分配给多个修改需求；接收到修改完成通知之后，将完成修改的接口文档组合形成接口文档集合；接收到开发者发出的第一指令之后，根据第一指令确定一主接口文档，第一指令用于指示接口文档集合中的一文档为主接口文档；将主接口文档部署至开发软件中，以使得开发软件运行时能够调用主接口文档。本发明解决了多个接口定义在同一接口文档中相互覆盖的问题，提高了开发效率、降低了开发成本。

Description

接口管理方法、装置、电子设备以及可读存储介质

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种接口管理方法、装置、电子设备以及可读存储介质。

背景技术

当前，对于软件的开发基本都采用前端与后端分离的方式，其基本流程大致为：后端开发者定义接口以提供数据服务，开发者通过开发页面调用接口以获取数据并渲染页面。由此，接口文档就显得十分重要。

现有的接口管理***，至少可以分为两类：第一类是纯文档型，***仅有编辑查看的功能，仅仅是用来前后端接口定义沟通，功能较单一，使用不便；第二类是***型，有对接口的各种管理，支持一些接口的导入导出，拥有权限控制。现有的接口管理***均存在当后端开发者根据多个不同需求对同一个接口文档进行修改时，基于不同需求的多个接口定义在同一接口文档中相互覆盖（即：接口文档中有且只能有一个需求被定义）的问题，致使现有软件的开发效率低、开发成本高。

发明内容

本发明实施例提供一种接口管理方法，以解决现有技术中当后端开发者根据不同需求对同一个接口文档进行修改时，基于不同需求的多个接口定义在同一接口文档中相互覆盖的问题。

为了解决上述技术问题，本发明是这样实现的：

第一方面，本发明实施例提供了一种接口管理方法，包括：

接收到后端开发者对同一接口文档的多个修改需求之后，将所述接口文档复制并保存多个，复制并保存后的所述接口文档的数量与所述修改需求的数量相等；

将多个所述接口文档一一对应地分配给多个所述修改需求；

接收到修改完成通知之后，将完成修改的所述接口文档组合形成接口文档集合；

接收到开发者发出的第一指令之后，根据所述第一指令确定一主接口文档，所述第一指令用于指示所述接口文档集合中的一文档为所述主接口文档；

将所述主接口文档部署至开发软件中，以使得所述开发软件运行时能够调用所述主接口文档。

可选地，将所述主接口文档部署至开发软件中，之后还包括：

接收到开发者发出的第二指令之后，根据所述第二指令确定次接口文档，所述第二指令用于在所述接口文档集合中指示出所述次接口文档；

基于开发者根据所述次接口文档对所述开发软件进行的修改，修改后的所述开发软件能够实现所述次接口文档的功能。

可选地，将所述主接口文档部署至开发软件中，包括：

采用CI方式将所述主接口文档部署在所述开发软件中。

可选地，采用CI方式将所述主接口文档部署在所述开发软件中，包括：

对所述主接口文档进行解析，根据解析结果生成数据包，所述数据包的格式为所述开发软件能够识读的数据交换格式；

接收到开发者发出的执行指令之后，运行所述开发软件以识读所述数据包，并将识读结果返回与所述开发者关联的开发页面。

可选地，所述开发软件至少是以下一项软件的二次开发软件：Apifox、Eolink、Yapi以及Swagger。

可选地，所述数据交换格式为json格式。

第二方面，本发明实施例提供了一种接口管理装置，包括：

接收模块，用于接收到后端开发者对同一接口文档的多个修改需求之后，将所述接口文档复制并保存多个，复制并保存后的所述接口文档的数量与所述修改需求的数量相等；

分配模块，用于将多个所述接口文档一一对应地分配给多个所述修改需求；

修改模块，用于接收到修改完成通知之后，将完成修改的所述接口文档组合形成接口文档集合；

结合模块，用于接收到开发者发出的第一指令之后，根据所述第一指令确定一主接口文档，所述第一指令用于指示所述接口文档集合中的一文档为所述主接口文档；

部署模块，用于将所述主接口文档部署至开发软件中，以使得所述开发软件运行时能够调用所述主接口文档。

可选地，所述结合模块，用于接收到开发者发出的第二指令之后，根据所述第二指令确定次接口文档，所述第二指令用于在所述接口文档集合中指示出所述次接口文档；

所述部署模块，用于根据所述次接口文档对所述开发软件进行修改，修改后的所述开发软件能够实现所述次接口文档的功能。

第三方面，本发明实施例提供了一种电子设备，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面中任一项所述的接口管理方法中的步骤。

第四方面，本发明实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面中任一项所述的接口管理方法中的步骤。

在本发明实施例中，通过在接收到后端开发者对同一接口文档的多个修改需求之后，将所述接口文档复制并保存多个，再将多个接口文档一一对应地分配给多个修改需求，解决了多个接口定义在同一接口文档中相互覆盖的问题，提高了软件的开发效率、降低了软件的开发成本。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例接口管理方法的流程示意图之一；

图2为本发明实施例接口管理方法的流程示意图之二；

图3为本发明实施例接口管理方法的流程示意图之三；

图4为本发明实施例接口管理装置的内部结构示意图；

图5为本发明实施例电子设备的内部结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供一种接口管理方法，参见图1所示， 图1为本发明实施例接口管理方法的流程示意图之一，包括：

步骤11：接收到后端开发者对同一接口文档的多个修改需求之后，将接口文档复制并保存多个，复制并保存后的接口文档的数量与修改需求的数量相等；

步骤12：将多个接口文档一一对应地分配给多个修改需求；

步骤13：接收到修改完成通知之后，将完成修改的接口文档组合形成接口文档集合；

步骤14：接收到开发者发出的第一指令之后，根据第一指令确定一主接口文档，第一指令用于指示接口文档集合中的一文档为主接口文档；

步骤15：将主接口文档部署至开发软件中，以使得开发软件运行时能够调用主接口文档。

本发明的一些实施例中，可选地，开发者对于主接口文档的选择可以是根据接口文档所对应的修改需求，例如，该修改需求可以是用于解决软件开发所亟待解决的问题的需求；该修改需求可以是用于完善上一个软件开发版本中报错部分的需求。

本发明实施例通过在接收到后端开发者对同一接口文档的多个修改需求之后，将所述接口文档复制并保存多个，再将多个接口文档一一对应地分配给多个修改需求，解决了多个接口定义在同一接口文档中相互覆盖的问题，提高了软件的开发效率、降低了软件的开发成本。

本发明的一些实施例中，可选地，参见图2所示， 图2为本发明实施例接口管理方法的流程示意图之二，将主接口文档部署至开发软件中，之后还包括：

步骤21：接收到开发者发出的第二指令之后，根据第二指令确定次接口文档，第二指令用于在接口文档集合中指示出次接口文档；

步骤22：基于开发者根据次接口文档对开发软件进行的修改，修改后的开发软件能够实现次接口文档的功能。

本发明的一些实施例中，可选地，开发者对于次接口文档的选择可以是根据接口文档所对应的修改需求，例如，该修改需求可以是用于解决软件开发所亟待解决的问题的需求，但该问题需要被解决的优先级低于主接口文档对应的修改需求所针对的问题；该修改需求可以是用于完善上一个软件开发版本中报错部分的需求，但该报错部分需要被完善的优先级低于主接口文档对应的修改需求所针对的报错部分。

本发明的一些实施例中，可选地，次接口文档可以是一个接口文档，也可以是多个接口文档。

本发明的一些实施例中，可选地，将主接口文档部署至开发软件中，包括：

采用CI方式将主接口文档部署在开发软件中。

CI（Continuous Integration，持续集成），通过持续集成开发人员能够频繁将代码集成到公共代码仓库的主分支中。开发人员能够在任何时候多次向仓库提交作品，而不是独立地开发每个功能模块并在开发周期结束时一一提交。

上述CI 的设置有利于将开发软件过程中的集成简化成一个简单、易于重复的日常开发任务，使得集成自动化，减少人工操作，有助于降低总体构建成本，并且有助于在开发周期的早期发现缺陷。

本发明的一些实施例中，可选地，参见图3所示， 图3为本发明实施例接口管理方法的流程示意图之三，采用CI方式将主接口文档部署在开发软件中，包括：

步骤31：对主接口文档进行解析，根据解析结果生成数据包，数据包的格式为开发软件能够识读的数据交换格式；

步骤32：接收到开发者发出的执行指令之后，运行开发软件以识读数据包，并将识读结果返回与开发者关联的开发页面。

本发明的一些实施例中，可选地，开发软件至少是以下一项软件的二次开发软件：Apifox、Eolink、Yapi以及Swagger。

Apifox通过一套***、一份数据，解决多个***之间的数据同步问题。只要定义好接口文档，接口调试、数据 Mock、接口测试就可以直接使用，无需再次定义；接口文档和接口开发调试使用同一个工具，接口调试完成后即可保证和接口文档定义完全一致。

Eolink支持 HTTP（S）、Websocket、TCP、UDP 等主流协议，通过代码注解自动生成API 文档,或者从 API 文档反向生成所有常见开发语言和框架的代码，节省 API 设计和开发时间。强大的 API 版本和变更管理让你不放过 API 的任何变动。

YAPI是由去哪儿网移动架构组（简称YMFE，一群由FE、iOS和Android工程师共同组成的最具想象力、创造力和影响力的大前端团队）开发的可视化接口管理工具，是一个可本地部署的、打通前后端及QA的接口管理平台。YAPI旨在为开发、产品和测试人员提供更优雅的接口管理服务，可以帮助开发者轻松创建、发布和维护不同项目，不同平台的API。有了YAPI，我们可以很方便的测试、管理和维护多个项目的API接口，不像Swagger那样是随应用生和灭的（且线上环境下大多数须关闭），YAPI是一个独立的服务平台。

Swagger 是一个规范且完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务。Swagger 的目标是对 REST API 定义一个标准且和语言无关的接口，可以让人和计算机拥有无须访问源码、文档或网络流量监测就可以发现和理解服务的能力。当通过 Swagger 进行正确定义，用户可以理解远程服务并使用最少实现逻辑与远程服务进行交互。与为底层编程所实现的接口类似，Swagger 消除了调用服务时可能会有的猜测。

Swagger支持 API 自动生成同步的在线文档：使用 Swagger 后可以直接通过代码生成文档，不再需要自己手动编写接口文档了，对程序员来说非常方便，可以节约写文档的时间去学习新技术。

Swagger提供 Web 页面在线测试 API：光有文档还不够，Swagger 生成的文档还支持在线测试。参数和格式都定好了，直接在界面上输入参数对应的值即可在线测试接口。

本发明的一些实施例中，可选地，数据交换格式为json格式。

JSON（JavaScript Object Notation，JS 对象简谱）是一种轻量级的数据交换格式。它基于 ECMAScript （欧洲计算机协会制定的js规范）的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。 易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。

本发明实施例提供一种接口管理装置40，参见图4所示，图4为本发明实施例接口管理装置的内部结构示意图，包括：

接收模块41，用于接收到后端开发者对同一接口文档的多个修改需求之后，将接口文档复制并保存多个，复制并保存后的接口文档的数量与修改需求的数量相等；

分配模块42，用于将多个接口文档一一对应地分配给多个修改需求；

修改模块43，用于接收到修改完成通知之后，将完成修改的接口文档组合形成接口文档集合；

结合模块44，用于接收到开发者发出的第一指令之后，根据第一指令确定一主接口文档，第一指令用于指示接口文档集合中的一文档为主接口文档；

部署模块45，用于将主接口文档部署至开发软件中，以使得开发软件运行时能够调用主接口文档。

本发明的一些实施例中，可选地，

结合模块44，还可以用于接收到开发者发出的第二指令之后，根据第二指令确定次接口文档，第二指令用于在接口文档集合中指示出次接口文档；

部署模块45，还可以用于根据次接口文档对开发软件进行修改，修改后的开发软件能够实现次接口文档的功能。

本发明的一些实施例中，可选地，

部署模块45，还可以用于采用CI方式将所述主接口文档部署在所述开发软件中。

本发明的一些实施例中，可选地，

部署模块45，还可以用于对所述主接口文档进行解析，根据解析结果生成数据包，所述数据包的格式为所述开发软件能够识读的数据交换格式；

部署模块45，还可以用于接收到开发者发出的执行指令之后，运行所述开发软件以识读所述数据包，并将识读结果返回与所述开发者关联的开发页面。

本申请实施例提供的接口管理装置能够实现图1至图3的方法实施例实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例提供了一种电子设备50，参见图5所示，图5为本发明实施例电子设备50的内部结构示意图，包括处理器51，存储器52及存储在存储器52上并可在处理器51上运行的程序或指令，程序或指令被处理器执行时实现本发明的任一项接口管理方法中的步骤。

本发明实施例提供了一种可读存储介质，可读存储介质上存储程序或指令，程序或指令被处理器执行时实现如上述任一项的接口管理方法的实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述的可读存储介质，如只读存储器（Read-Only Memory，简称ROM）、随机存取存储器（Random Access Memory，简称RAM）、磁碟或者光盘等。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。

Claims (10)

1.一种接口管理方法，其特征在于：包括：

接收到后端开发者对同一接口文档的多个修改需求之后，将所述接口文档复制并保存多个，复制并保存后的所述接口文档的数量与所述修改需求的数量相等；

将多个所述接口文档一一对应地分配给多个所述修改需求；

接收到修改完成通知之后，将完成修改的所述接口文档组合形成接口文档集合；

接收到开发者发出的第一指令之后，根据所述第一指令确定一主接口文档，所述第一指令用于指示所述接口文档集合中的一文档为所述主接口文档；

将所述主接口文档部署至开发软件中，以使得所述开发软件运行时能够调用所述主接口文档。

2.根据权利要求1所述的接口管理方法，其特征在于：将所述主接口文档部署至开发软件中，之后还包括：

接收到开发者发出的第二指令之后，根据所述第二指令确定次接口文档，所述第二指令用于在所述接口文档集合中指示出所述次接口文档；

基于开发者根据所述次接口文档对所述开发软件进行的修改，修改后的所述开发软件能够实现所述次接口文档的功能。

3.根据权利要求1所述的接口管理方法，其特征在于：将所述主接口文档部署至开发软件中，包括：

采用CI方式将所述主接口文档部署在所述开发软件中。

4.根据权利要求3所述的接口管理方法，其特征在于：采用CI方式将所述主接口文档部署在所述开发软件中，包括：

对所述主接口文档进行解析，根据解析结果生成数据包，所述数据包的格式为所述开发软件能够识读的数据交换格式；

接收到开发者发出的执行指令之后，运行所述开发软件以识读所述数据包，并将识读结果返回与所述开发者关联的开发页面。

5.根据权利要求4所述的接口管理方法，其特征在于：所述开发软件至少是以下一项软件的二次开发软件：Apifox、Eolink、Yapi以及Swagger。

6.根据权利要求4所述的接口管理方法，其特征在于：所述数据交换格式为json格式。

7.一种接口管理装置，其特征在于：包括：

接收模块，用于接收到后端开发者对同一接口文档的多个修改需求之后，将所述接口文档复制并保存多个，复制并保存后的所述接口文档的数量与所述修改需求的数量相等；

分配模块，用于将多个所述接口文档一一对应地分配给多个所述修改需求；

修改模块，用于接收到修改完成通知之后，将完成修改的所述接口文档组合形成接口文档集合；

结合模块，用于接收到开发者发出的第一指令之后，根据所述第一指令确定一主接口文档，所述第一指令用于指示所述接口文档集合中的一文档为所述主接口文档；

部署模块，用于将所述主接口文档部署至开发软件中，以使得所述开发软件运行时能够调用所述主接口文档。

8.根据权利要求7所述的接口管理装置，其特征在于：

所述结合模块，用于接收到开发者发出的第二指令之后，根据所述第二指令确定次接口文档，所述第二指令用于在所述接口文档集合中指示出所述次接口文档；

所述部署模块，用于根据所述次接口文档对所述开发软件进行修改，修改后的所述开发软件能够实现所述次接口文档的功能。

9.一种电子设备，其特征在于：包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1至6中任一项所述的接口管理方法中的步骤。

10.一种可读存储介质，其特征在于：所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如权利要求1至6中任一项所述的接口管理方法中的步骤。

Images