基于swagger文档的类型声明文件生成方法及装置与流程

1.本技术实施例涉及计算机技术领域，尤其涉及一种基于swagger文档的类型声明文件生成方法及装置。


背景技术：

2.随着互联网技术的发展，网站的前端与后端开始分离。在前端与后端的交互过程中api(application programming interface，应用程序编程接口)接口便成为一个重要的途径。api文档也因此成了开发人员与其他工作人员的重要纽带。swagger是一种api开发工具，可用编写swagger文档。swagger文档是前后端联调过程中，后端人员提供给前端开发人员的文档，属于双方的一个共同约定。
3.现有技术中，在生成swagger文档后，可以通过swagger
‑
to
‑
ts插件将该swagger文档生成类型声明文件，然而，发明人发现，现有的swagger
‑
to
‑
ts插件在生成类型声明文件时都是先将所有的类型生成一个文件，然后再去依次获取调用，导致生成的内容过于臃肿，调用使用时非常不方便。


技术实现要素：

4.本技术实施例的目的是提供一种基于swagger文档的类型声明文件生成方法及装置、计算机设备及计算机可读存储介质，以解决现有的swagger
‑
to
‑
ts插所生成的内容过于臃肿，导致调用使用时非常不方便的问题。
5.本技术实施例的一个方面提供了一种基于swagger文档的类型声明文件生成方法，所述方法包括：
6.获取多个接口的接口请求路径；
7.获取开发项目对应的swagger文档中包含的json数据；
8.根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体；
9.根据各个接口的第一数据结构体从所述json数据中获取预设类型的第一字段数据，以及根据各个接口的第二数据结构体从所述json数据中获取所述预设类型的第二字段数据；
10.将各个接口对应的第一字段数据与各个接口对应的第二字段数据按照预设的第一类型声明文件生成规则生成所述开发项目的类型声明文件。
11.可选地，所述方法还包括：
12.根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的接口信息，所述接口信息包括接口的描述信息、接口请求路径、接口的入参信息以及接口的出参信息；
13.将各个接口的接口信息按照预设的第二类型声明文件生成规则生成所述开发项
目的前端接口文件；
14.将所述前端接口文件插入所述类型声明文件中。
15.可选地，所述获取多个接口的接口请求路径包括：
16.获取所述开发项目的配置文件；
17.从所述配置文件中读取用户配置的接口请求路径筛选条件；
18.根据所述接口请求路径筛选条件确定多个接口的接口请求路径。
19.可选地，所述根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体包括：
20.根据接口请求路径遍历所述json数据，并从所述json数据中找到第一个接口的入参信息以及出参信息；
21.分别从所述第一个接口的入参信息和出参信息中获取第一数据结构体和第二数据结构体；
22.根据所述接口请求路径继续遍历所述json数据，并从所述json数据中获取下一个接口的入参信息和出参信息，以及从下一个接口的入参信息和出参信息中获取第一数据结构体和第二数据结构体，直至所有接口的第一数据结构体和第二数据结构体获取完毕为止。
23.可选地，所述分别从所述第一个接口的入参信息和出参信息中获取第一数据结构体和第二数据结构体包括：
24.对包含所述第一个接口的入参信息的第一数组进行循环解析，以从所述第一数组中解析得到所述第一数组中的最后一个字段，并将得到的最后一个字段作为所述第一数据结构体；
25.对包含所述第一个接口的出参信息的第二数组进行循环解析，以从所述第二数组中解析得到所述第二数组中的最后一个字段，并将得到的最后一个字段作为所述第二数据结构体。
26.可选地，所述根据各个接口的第一数据结构体从所述json数据中获取预设类型的第一字段数据包括：
27.根据各个接口的第一数据结构体从所述json数据中获取与所述第一数据结构体相匹配的第三数组；
28.从所述第三数组中获取所述预设类型的第一字段数据；
29.所述根据各个接口的第二数据结构体从所述json数据中获取所述预设类型的第二字段数据包括：
30.根据各个接口的第二数据结构体从所述json数据中获取与所述第二数据结构体相匹配的第四数组；
31.从所述第四数组中获取所述预设类型的第二字段数据。
32.可选地，所述方法还包括：
33.轮询获取开发项目对应的swagger文档中包含的json数据；
34.判断新获取到的json数据是否发生变化，若发生变化，则返回执行根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包
含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体的步骤，并生成提示消息。
35.本技术实施例的再一个方面提供了一种基于swagger文档的类型声明文件生成装置，包括：
36.第一获取模块，用于获取多个接口的接口请求路径；
37.第二获取模块，用于获取开发项目对应的swagger文档中包含的json数据；
38.遍历模块，用于根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体；
39.第三获取模块，用于根据各个接口的第一数据结构体从所述json数据中获取预设类型的第一字段数据，以及根据各个接口的第二数据结构体从所述json数据中获取所述预设类型的第二字段数据；
40.生成模块，用于将各个接口对应的第一字段数据与各个接口对应的第二字段数据按照预设的第一类型声明文件生成规则生成所述开发项目的类型声明文件。
41.本技术实施例的再一个方面提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，上述处理器执行上述计算机程序时用于实现如上任一项所述的方法的步骤。
42.本技术实施例的又一个方面提供了一种计算机可读存储介质，其上存储有计算机程序，上述计算机程序被处理器执行时用于实现如上任一项所述的方法的步骤。
43.本技术实施例提供的基于swagger文档的类型声明文件生成方法、装置、计算机设备及计算机可读存储介质，根据多个接口的接口请求路径来从json数据中找到最终需要生成类型声明文件的第一字段数据和第二字段数据，而无需对所有接口都获取第一字段数据和第二字段数据，从而可以使得最终生成的类型声明文件不会过于臃肿，在调用时非常简便。
附图说明
44.图1示意性示出了实现本技术实施例的基于swagger文档的类型声明文件生成方法的环境示意图；
45.图2示意性示出了根据本技术一实施例的基于swagger文档的类型声明文件生成方法的流程图；
46.图3示意性示出了本技术一实施例中的获取多个接口的接口请求路径的步骤流程细化示意图；
47.图4示意性示出了根据本技术一实施例根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体的步骤流程细化流程图；
48.图5示意性示出了根据本技术一实施例分别从所述第一个接口的入参信息和出参信息中获取第一数据结构体和第二数据结构体的步骤流程细化流程图；
49.图6示意性示出了根据本技术另一实施例基于swagger文档的类型声明文件生成方法的流程图；
50.图7示意性示出了根据本技术实施例的基于swagger文档的类型声明文件生成装置的框图；
51.图8示意性示出了根据本技术实施例的适于实现基于swagger文档的类型声明文件生成方法的计算机设备的硬件架构示意图。
具体实施方式
52.以下结合附图与具体实施例进一步阐述本技术的优点。
53.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
54.在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
55.应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
56.在本技术的描述中，需要理解的是，步骤前的数字标号并不标识执行步骤的前后顺序，仅用于方便描述本技术及区别每一步骤，因此不能理解为对本技术的限制。
57.本技术提供的基于swagger文档的类型声明文件生成方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
58.终端102上运行了第一系统以及swagger。服务器104上运行了第二系统。终端102在处理工作任务时，可以通过第一系统向第二系统发起业务请求。第二系统响应该业务请求，调用多个接口依照业务流程执行该业务请求。在执行完毕后，第二系统向第一系统返回各个接口的响应数据。终端102中swagger对各个接口的响应数据等进行记录，生成原生swagger文件。终端102利用原生swagger文件生成json文件。之后，终端102可以利用json文件生成类型声明文件及前端接口文件。
59.参阅图2，其为本技术一实施例的基于swagger文档的类型声明文件生成方法的流程示意图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。从图中可以看出，本实施例中所提供的基于swagger文档的类型声明文件生成方法包括：
60.步骤s20、获取多个接口的接口请求路径。
61.具体地，所述接口请求路径为接口的请求地址，作为示例，接口请求路径可以以如下格式进行表示：path:/mal1
‑
c/api/***，即以path字段来表示某一个接口的接口请求路径，path字段对应的内容来表示该接口具体的接口请求路径，也就是说，/mal1
‑
c/api/***
表示当前接口的接口请求路径。
62.在一示例性的实施方式中，可以先将多个接口的接口请求路径存储在一个预设文件中，当后续需要获取接口请求路径时，即可以直接从该预设文件中获取。
63.在另一示例性的实施方式中，参照图3，所述获取多个接口的接口请求路径包括：
64.步骤s30，获取所述开发项目的配置文件。
65.具体地，所述开发项目为用户当前进行开发的项目，比如，用户当前在对软件项目a进行开发，则该软件项目a即为所述开发项目。
66.所述配置文件为用于存储所述开发项目的配置信息的文件。在本实施例中，该配置文件可以包括所述开发项目对应的swagger文档的地址，以及用户预先配置的用户确定需要对哪些接口生成类型声明文件的接口请求路径筛选条件。
67.在一实施方式中，可以通过nodejs的路径模块(path模块)来从开发项目的目录中找到开发项目的配置文件，比如autoapi.config.js。
68.其中，nodejs是一种基于javascript语言的后台语言，它让js拥有了操作io/fs/持久化等后台才拥有的能力。
69.步骤s31，从所述配置文件中读取用户配置的接口请求路径筛选条件。
70.具体地，所述接口请求路径筛选条件为用于确定需要对哪些接口进行处理的匹配规则，在本实施例方式中，该接口请求路径筛选条件可以为一个正则表达式，比如为如下所示的正则表达式：/mall
‑
c/activity_626/，该表达式代表从待筛选字符串中找出包含该字符串的接口请求路径。
71.在另一实施方式中，该接口请求筛选条件也可以直接为多个接口的接口请求路径对应的字符串。
72.在本实施方式中，可以通过nodejs的文件读取模块(fs模块)从配置文件中读取出请求路径筛选条件，在一实施方式中，可以通过fs模块读取配置文件中的includes字段来获取所述请求路径筛选条件。
73.步骤s32，根据所述接口请求路径筛选条件确定多个接口的接口请求路径。
74.具体地，在得到接口请求路径筛选条件后，即可以方便地根据筛选条件来得出多个接口的接口请求路径。
75.在一实施方式中，当接口请求路径筛选条件直接为多个接口的接口请求路径对应的字符串时，则可以确定这些字符串即为多个接口的接口请求路径。
76.在另一实施方式中，当接口请求路径筛选条件为正则表达式时，则可以确定所有包含该正则表达式的字符串都为接口的接口请求路径。
77.作为示例，正则表达式为：/mall
‑
c/activity_626/，则字符串：/mall
‑
c/activity_626/124/、/mall
‑
c/activity_626/asd/、/mall
‑
c/activity_626/124/dddd/等都为接口的接口请求路径。
78.步骤s21，获取开发项目对应的swagger文档中包含的json数据。
79.具体地，在开发项目时，为了方便前后端联调，后端人员会在开发项目的过程中编写swagger文档供前端开发人员进行参考，其中，swagger文档属于双发的一个共同约定。
80.在本实施例中，可以通过ajax请求向服务端获取swagger文档中包含的json数据，其中，该ajax请求包括swagger文档的地址。
81.在本实施例中，json数据包括所有接口的接口信息，其中，接口信息可以包括接口的接口请求路径信息、接口的入参信息以及接口的出参信息等。
82.步骤s22，根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体。
83.具体地，每一个接口的接口信息在json数据中保存时，是以接口请求路径开始进行保存的，因此，在获取每一个接口的接口信息时，即可以通过该接口的接口请求路径来在定位该接口的接口信息在json数据中的位置。
84.在本实施例中，根据接口请求路径的方式来遍历json数据，可以依次从json数据中找到各个接口的接口信息。
85.在找到第一个接口的接口信息后，可以继续从该接口信息中获取当前接口的入参信息和出参信息，其中，入参信息中可以包括多个入参对象和多个入参对象的属性信息，其中，属性信息可以包括入参对象的接口字段名、字段类型、字段长度、字段描述信息、第一数据结构体等。同理，出参信息中也可以包括多个出参对象和多个出参对象的属性信息，其中，属性信息可以包括出参对象的接口字段名、字段类型、字段长度、字段描述信息、第二数据结构体等。
86.在本实施例中，第一数据结构体用于确定入参中需要生成类型声明文件的数据结构体，该数据结构体中包含有多个数据字段。
87.第二数据结构体用于确定出参中需要生成类型声明文件的数据结构体，该数据结构体中包含有多个数据字段。
88.在一示例性的实施方式中，参照图4，所述根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体包括：步骤s40，根据接口请求路径遍历所述json数据，以从所述json数据中找到第一个接口的入参信息以及出参信息；步骤s41，分别从所述第一个接口的入参信息和出参信息中获取第一数据结构体和第二数据结构体；步骤s42，根据所述接口请求路径继续遍历所述json数据，并从所述json数据中获取下一个接口的入参信息和出参信息，以及从下一个接口的入参信息和出参信息中获取第一数据结构体和第二数据结构体，直至所有接口的第一数据结构体和第二数据结构体获取完毕为止。
89.具体地，通过接口请求路径先从json数据中找到第一个接口的入参信息以及出参信息，之后，可以分别从入参信息和出参信息中找到第一数据结构体和第二数据结构体，并在找到第一数据结构体和第二数据结构体之后，将其存储至内存中。
90.在找到第一个接口的第一数据结构体和第二数据结构体之后，继续根据接口请求路径遍历余下的json数据，直到找到下一个接口(第二个接口)的出参信息和入参信息，之后会从该第二接口的出参信息和入参信息中获取第一数据结构体和第二数据结构体。之后，重复上述操作，直到根据接口请求路径直到所有接口的第一数据结构体和第二数据结构体为止。
91.在一示例性的实施方式中，参照图5，所述分别从所述第一个接口的入参信息和出参信息中获取第一数据结构体和第二数据结构体包括：步骤s50，对包含所述第一个接口的入参信息的第一数组进行循环解析，以从所述第一数组中解析得到所述第一数组中的最后
一个字段，并将得到的最后一个字段作为所述第一数据结构体；步骤s51，对包含所述第一个接口的出参信息的第二数组进行循环解析，以从所述第二数组中解析得到所述第二数组中的最后一个字段，并将得到的最后一个字段作为所述第二数据结构体。
92.作为示例，第一个接口的入参信息如下：
[0093][0094][0095]
其中，"parameters"代表入参信息的字段，该字段后面的内容代表具体的入参信息。“[]”中的内容代表所述第一数组。
[0096]
本实施例中，通过对该第一数组进行循环解析，以便可以依次得到第一数组中的
每一层内容中，在得到每一层的内容之后，将该第一数组中的最后一个字段作为所述第一数据结构体，即将字段firstlookorderinfoquery作为所述第一数据结构体。
[0097]
同理，在获取第二数据结构体时，参照上述方法对出参信息的第二数组进行解析，以获取到第二数据结构体。作为示例，可以用“response”代表出参信息的字段，该字段后面的内容代表具体的出参信息。“[]”中的内容代表第二数组。
[0098]
步骤s23，根据各个接口的第一数据结构体从所述json数据中获取预设类型的第一字段数据，以及根据各个接口的第二数据结构体从所述json数据中获取所述预设类型的第二字段数据。
[0099]
具体地，在得到各个接口的第一数据结构体之后，可以根据各个接口的第一结构体从json数据中找到该第一数据结构体相匹配的第三数组，之后从该第三数组中获取到所述预设类型的第一字段数据。
[0100]
其中，所述预设类型为预先设定的数据字段。
[0101]
作为示例，j假设根据第一数据结构体cartcouponltemsnumvo获取到的第三数组如下：
[0102]
[0103][0104]
其中，cartcouponltemsnumvo代表第一数据结构体，该字段后面的内容代表该第一数据结构体中具体包含的数据，即所述第三数组中包含的数据，所述预设类型为所述第三数组中的"properties"字段，即属性字段，所述属性字段对应的数据内容即为所述第一字段数据。
[0105]
在一实施方式中，可以将属性字段中包含的所有字段数据作为所述第一字段数据，也可以将属性字段中包含的部分字段数据作为所述第一字段数据，具体选择哪些字段数据作为所述第一字段数据在本实施例中不作限定，可以根据实际情况进行设定，比如，选择字段数据“code：integer,//返回的错误码”，以及字段数据“message：string,//返回的错误描述码”作为所述第一字段数据。
[0106]
同理，在得到各个接口的第二数据结构体之后，可以根据各个接口的第二结构体从json数据中找到该第二数据结构体相匹配的第四数组，之后从该第四数组中获取到所述预设类型的第二字段数据。
[0107]
其中，具体获取第二字段数据的方法参照上述获取第一字段数据的方法，在本实
施例中不再赘述。
[0108]
步骤s24，将各个接口对应的第一字段数据与各个接口对应的第二字段数据按照预设的第一类型声明文件生成规则生成所述开发项目的类型声明文件。
[0109]
具体地，所述第一类型声明文件生成规则为用于拼接各个接口的第一字段数据与第二字段数据来生成类型声明文件的规则，该规则是用户预先定义的，其可以根据实际情况进行修改与调整。
[0110]
作为示例，该第一类型声明文件生成规则可以为如下格式：interface 接口的数据结构体(第一数据结构体或第二数据结构体){第一字段数据或第二字段数据}
[0111]
在一具体实施方式中，生成的类型声明文件如下所示：
[0112]
interface buddyassistrecordouery{
[0113]
assistmid:number，
[0114]
beassistecmid:nunber
[0115]
}
[0116]
interface luckdramouery{
[0117]
jackpotid:number，
[0118]
mid:nunber，
[0119]
portrait:string，
[0120]
uname:string，
[0121]
}
[0122]
其中，buddyassistrecordouery代表接口的第一数据结构体，luckdramouery代表接口的第二数据结构体，assistmid:number，beassistecmid:nunber代表第一字段数据，jackpotid:number、mid:nunber，、portrait:string，、uname:string，代表第二字段数据。
[0123]
其中，所述类型声明文件为ts文件，用于提供javascript的静态类型检测，弥补弱语言的劣势，是javascript的超集。
[0124]
本实施例中的类型声明文件生成方法，根据多个接口的接口请求路径来从json数据中找到最终需要生成类型声明文件的第一字段数据和第二字段数据，而无需对所有接口都获取第一字段数据和第二字段数据，从而可以使得最终生成的类型声明文件不会过于臃肿，在调用时非常简便。
[0125]
在一示例性的实施方式中，参照图6，所述方法还包括：
[0126]
步骤s60，根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的接口信息，所述接口信息包括接口的描述信息、接口请求路径、接口的入参信息以及接口的出参信息。
[0127]
具体地，所述描述信息为用于对接口进行描述的信息，其可以包括接口的名称、接口的备注信息等。
[0128]
作为示例，获取到的一个接口的部分接口信息如下：
[0129]“paths”：{
[0130]
"/mall
‑
c/api/***"：{
[0131]
"get"：{
[0132]
"tags"：[
[0133]
"merchants
‑
controller”[0134]“summary”："***"，
[0135]
"operationtd"："***"，
[0136]
"consumes"：[
[0137]“application/json"
[0138]
"produces：
[0139]“*/*”[0140]
]，
[0141]
parameters"：[
[0142]“name”："***"，
[0143]“in"："***"，
[0144]“description”：”***”[0145]“required"：false，"type"："***"，
[0146]“format"："***"
[0147]
}，
[0148]
{
[0149]“name”："***"，
[0150]“in"："***"，
[0151]“description”："***"
[0152]
其中，tag和summary字段为接口的描述信息，parameters字段作为接口的入参信息，response字段(未示出)作为接口的出参信息。
[0153]
path字段为接口请求路径字段，/mall
‑
c/api/***为接口的接口请求路径。
[0154]
步骤s61，将各个接口的接口信息按照预设的第二类型声明文件生成规则生成所述开发项目的前端接口文件。
[0155]
具体地，所述第二类型声明文件生成规则为用于拼接各个接口的接口描述信息、接口请求路径、接口的入参信息、与接口的出参信息生成前端接口文件的规则，该规则是用户预先定义的，其可以根据实际情况进行修改与调整。
[0156]
作为示例，该第二类型声明文件生成规则可以为如下拼接规则：接口描述信息
[0157]
export const接口请求路径中的最后一个字段 入参信息或出参信息 fetch{url：接口请求路径？ 入参信息或出参信息}。
[0158]
需要说明的是，在上述拼接规则中的入参信息或出参信息具体选择的出入参字段数据可以根据实际情况进行设定与调整，在本实施例中不作限定，同理，接口描述信息中具体选择的字段数据也可以根据实际情况进行设定与调整，在本实施例中也不作限定。
[0159]
在一具体实施方式中，生成的前端接口文件中的部分字符串如下所示：
[0160]
//merchants
‑
controlter***
[0161]
export const top＝(shop_id:number，pagetype:string)＝>fetch({url:'/mall
‑
c/api/merchants/goods/top？shop_id pagetype：
[0162]
其中，“//merchants
‑
controlter***”代表接口描述信息，“top”代表接口请求路径的最后一个字段，“shop_id:number，pagetype:string”代表接口中的入参字段数据，
“
mall
‑
c/api/merchants/goods/top”代表接口的接口请求路径。
[0163]
步骤s62，将所述前端接口文件插入所述类型声明文件中。
[0164]
具体地，可以将前端接口文件插入类型声明文件中的最后面，也可以将前端接口文件放入类型声明文件的最前面，在本实施中不作限定。
[0165]
其中，所述前端接口文件为用于方便前端参照该文件进行前端接口开发的文件。
[0166]
本实施例中，通过在生成类型声明文件的同时生成前端接口文件，而无需用户进行手动编写，从而可以省掉开发人员编写文件的时间，提高开发效率。
[0167]
在一示例性的实施方式中，在将前端接口文件插入至类型声明文件之后，为了方便用户查找，可以通过nodejs的fs和path模块，将该文件写到工作目录下面的api.ts文件中。
[0168]
在一示例性的实施方式中，为了避免swagger文档发生变更后，前端人员还需要等待后端主动告知，之后，再进行获取swagger文档导致联调效率低下的问题，本实施例中，在生成类型声明文件之后，可以轮询获取开发项目对应的swagger文档中包含的json数据，并在获取到json数据之后，与前一次获取到的json数据进行对比，若发现json数据发生了变化，则返回执行根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体的步骤，以重新生成新的类型声明文件。
[0169]
在本实施例中，为了用户可以及时知道有新的类型声明文件生成，可以通过在页面上生成提示消息的方式来提醒用户。
[0170]
参阅图7所示，是本技术基于swagger文档的类型声明文件生成装置70一实施例的程序模块图。
[0171]
本实施例中，所述基于swagger文档的类型声明文件生成装置70包括一系列的存储于存储器上的计算机程序指令，当该计算机程序指令被处理器执行时，可以实现本技术各实施例的基于swagger文档的类型声明文件生成功能。在一些实施例中，基于该计算机程序指令各部分所实现的特定的操作，基于swagger文档的类型声明文件生成装置70可以被划分为一个或多个模块，具体可以划分的模块如下：
[0172]
第一获取模块71，用于获取多个接口的接口请求路径；
[0173]
第二获取模块72，用于获取开发项目对应的swagger文档中包含的json数据；
[0174]
遍历模块73，用于根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体；
[0175]
第三获取模块74，用于根据各个接口的第一数据结构体从所述json数据中获取预设类型的第一字段数据，以及根据各个接口的第二数据结构体从所述json数据中获取所述预设类型的第二字段数据；
[0176]
生成模块75，用于将各个接口对应的第一字段数据与各个接口对应的第二字段数据按照预设的第一类型声明文件生成规则生成所述开发项目的类型声明文件。
[0177]
在一示例性的实施方式中，所述基于swagger文档的类型声明文件生成装置70还包括：第四获取模块及插入模块，其中：
[0178]
第四获取模块，用于根据多个接口的接口请求路径遍历所述json数据，并从所述
json数据中获取每一个接口的接口信息，所述接口信息包括接口的描述信息、接口请求路径、接口的入参信息以及接口的出参信息；
[0179]
生成模块75，还用于将各个接口的接口信息按照预设的第二类型声明文件生成规则生成所述开发项目的前端接口文件；
[0180]
插入模块，用于将所述前端接口文件插入所述类型声明文件中。
[0181]
在一示例性的实施方式中，所述第一获取模块71，还用于获取所述开发项目的配置文件；从所述配置文件中读取用户配置的接口请求路径筛选条件；根据所述接口请求路径筛选条件确定多个接口的接口请求路径。
[0182]
在一示例性的实施方式中，所述遍历模块73，还用于根据接口请求路径遍历所述json数据，并从所述json数据中找到第一个接口的入参信息以及出参信息；分别从所述第一个接口的入参信息和出参信息中获取第一数据结构体和第二数据结构体；根据所述接口请求路径继续遍历所述json数据，并从所述json数据中获取下一个接口的入参信息和出参信息，以及从下一个接口的入参信息和出参信息中获取第一数据结构体和第二数据结构体，直至所有接口的第一数据结构体和第二数据结构体获取完毕为止。
[0183]
在一示例性的实施方式中，所述遍历模块73，还用于对包含所述第一个接口的入参信息的第一数组进行循环解析，以从所述第一数组中解析得到所述第一数组中的最后一个字段，并将得到的最后一个字段作为所述第一数据结构体；对包含所述第一个接口的出参信息的第二数组进行循环解析，以从所述第二数组中解析得到所述第二数组中的最后一个字段，并将得到的最后一个字段作为所述第二数据结构体。
[0184]
在一示例性的实施方式中，第三获取模块74，还用于根据各个接口的第一数据结构体从所述json数据中获取与所述第一数据结构体相匹配的第三数组；从所述第三数组中获取所述预设类型的第一字段数据。
[0185]
第三获取模块74，还用于根据各个接口的第二数据结构体从所述json数据中获取与所述第二数据结构体相匹配的第四数组；从所述第四数组中获取所述预设类型的第二字段数据。
[0186]
在一示例性的实施方式中，所述基于swagger文档的类型声明文件生成装置70还包括：轮询模块及判断模块，其中：
[0187]
轮询模块，用于轮询获取开发项目对应的swagger文档中包含的json数据；
[0188]
判断模块，用于判断新获取到的json数据是否发生变化，若发生变化，则返回执行根据多个接口的接口请求路径遍历所述json数据，并从所述json数据中获取每一个接口的入参信息中包含的第一数据结构体及每一个接口的出参信息中包含的第二数据结构体的步骤，并生成提示消息。
[0189]
本实施例根据多个接口的接口请求路径来从json数据中找到最终需要生成类型声明文件的第一字段数据和第二字段数据，而无需对所有接口都获取第一字段数据和第二字段数据，从而可以使得最终生成的类型声明文件不会过于臃肿，在调用时非常简便。
[0190]
图8示意性示出了根据本技术实施例的适于实现基于swagger文档的类型声明文件生成方法的计算机设备8的硬件架构示意图。本实施例中，计算机设备8是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器
(包括独立的服务器，或者多个服务器所组成的服务器集群)等。如图8所示，计算机设备8至少包括但不限于：可通过系统总线相互通信链接存储器120、处理器121、网络接口122。其中：
[0191]
存储器120至少包括一种类型的计算机可读存储介质，该可读存储介质可以是易失性的，也可以是非易失性的，具体而言，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器120可以是计算机设备8的内部存储模块，例如该计算机设备8的硬盘或内存。在另一些实施例中，存储器120也可以是计算机设备8的外部存储设备，例如该计算机设备8上配备的插接式硬盘，智能存储卡(smart media card，简称为smc)，安全数字(secure digital，简称为sd)卡，闪存卡(flash card)等。当然，存储器120还可以既包括计算机设备8的内部存储模块也包括其外部存储设备。本实施例中，存储器120通常用于存储安装于计算机设备8的操作系统和各类应用软件，例如基于swagger文档的类型声明文件生成方法的程序代码等。此外，存储器120还可以用于暂时地存储已经输出或者将要输出的各类数据。
[0192]
处理器121在一些实施例中可以是中央处理器(central processing unit，简称为cpu)、控制器、微控制器、微处理器、或其它基于swagger文档的类型声明文件生成芯片。该处理器121通常用于控制计算机设备8的总体操作，例如执行与计算机设备8进行数据交互或者通信相关的控制和处理等。本实施例中，处理器121用于运行存储器120中存储的程序代码或者处理数据。
[0193]
网络接口122可包括无线网络接口或有线网络接口，该网络接口122通常用于在计算机设备8与其它计算机设备之间建立通信链接。例如，网络接口122用于通过网络将计算机设备8与外部终端相连，在计算机设备8与外部终端之间的建立数据传输通道和通信链接等。网络可以是企业内部网(intranet)、互联网(internet)、全球移动通讯系统(global system of mobile communication，简称为gsm)、宽带码分多址(wideband code division multiple access，简称为wcdma)、4g网络、5g网络、蓝牙(bluetooth)、wi
‑
fi等无线或有线网络。
[0194]
需要指出的是，图8仅示出了具有部件120～122的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。
[0195]
在本实施例中，存储于存储器120中的基于swagger文档的类型声明文件生成方法可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器121)所执行，以完成本技术。
[0196]
本技术实施例提供了一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的基于swagger文档的类型声明文件生成方法的步骤。
[0197]
本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算
机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(smart media card，简称为smc)，安全数字(secure digital，简称为sd)卡，闪存卡(flash card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中的基于swagger文档的类型声明文件生成方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。
[0198]
以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到至少两个网络单元上。可以根据实际的需要筛选出其中的部分或者全部模块来实现本技术实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
[0199]
通过以上的实施方式的描述，本领域普通技术人员可以清楚地了解到各实施方式可借助软件加通用硬件平台的方式来实现，当然也可以通过硬件。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(read
‑
onlymemory，rom)或随机存储记忆体(randomaccessmemory，ram)等。
[0200]
最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。