API类生成方法、装置、电子设备和可读存储介质与流程

文档序号:30084145发布日期:2022-05-18 05:11阅读:111来源:国知局
API类生成方法、装置、电子设备和可读存储介质与流程
api类生成方法、装置、电子设备和可读存储介质
技术领域
1.本技术涉及应用程序开发技术领域,具体而言,涉及一种api类生成方法、装置、电子设备和可读存储介质。


背景技术:

2.api(application programming interface,应用程序接口)是所有需要前端开发和后端开发共同参与的工作流程中的中间关键环节。常规的研发工作流包括:在需求和技术方案确定后,开发需要手动维护一份api文档以及手动编写供实例化和运行的类或模型,但是手动编写的效率相对较低,且人为的操作方式可能存在一些人为误差。


技术实现要素:

3.本技术的目的在于提供一种api类生成方法、装置、电子设备和计算机可读存储介质,以改善现有的后端开发需要开发人员手动维护api文档,效率低的问题。
4.第一方面,本发明提供一种api类生成方法,包括:
5.获取目标api的后端处理请求;
6.根据所述目标api的代码仓库,确定出接口描述文件;
7.对所述接口描述文件进行解析,确定出api文档;
8.确定出多个操作系统下的代码仓库集;
9.基于所述接口描述文件,生成多个操作系统下的api类数据。
10.在可选的实施方式中,所述根据所述目标api的代码仓库,确定出接口描述文件,包括:
11.克隆所述目标api的代码仓库;
12.通过编译工具,编译所述代码仓库中的代码,生成接口描述文件。
13.在可选的实施方式中,基于所述接口描述文件,生成多个操作系统下的api类数据,包括:
14.确定出多个操作系统下的代码仓库集;
15.根据所述代码仓库集中各个代码仓库匹配的执行脚本,确定出多个操作系统下的api类。
16.在可选的实施方式中,所述多个操作系统包括:ios操作系统和安卓操作系统;所述根据所述代码仓库集中各个代码仓库匹配的执行脚本,确定出多个操作系统下的api类,包括:
17.使用所述代码仓库集中的ios操作系统的代码仓库对应的ruby脚本,执行所述ios操作系统的代码仓库中的模板文件,得到ios操作系统下的第一api类数据;
18.使用所述代码仓库集中的安卓操作系统的代码仓库对应的shell脚本,执行所述安卓操作系统的代码仓库中的模板文件,得到安卓操作系统下的第二api类数据。
19.在可选的实施方式中,所述确定出多个操作系统下的代码仓库集,包括:
20.获取所述多个操作系统下的配置参数;
21.根据所述多个操作系统下的配置参数,确定出所述多个操作系统下的代码仓库集。
22.在可选的实施方式中,所述方法还包括:
23.根据所述api文档,确定出目标应用服务组和目标api信息;
24.根据所述目标应用服务组和所述目标api,生成模拟接口数据,所述模拟接口数据用于调试所述目标api对应的目标客户端。
25.在可选的实施方式中,所述代码仓库集中的各个代码仓库中包括类模板文件;所述根据所述代码仓库集中各个代码仓库匹配的执行脚本,确定出多个操作系统下的api类数据,包括:
26.根据所述代码仓库集中各个代码仓库匹配的执行脚本,确定出多个操作系统下的api类;
27.将所述多个操作系统下的api类,填充至各个操作系统下的类模板文件中,以形成api类文件。
28.在可选的实施方式中,应用于后台服务器,所述方法还包括:
29.向所述目标api的代码仓库所在终端发送后台服务器的服务账号,以供所述目标api的代码仓库所在终端对所述服务账号的权限进行验证,得到验证结果;
30.若所述验证结果表征所述服务账号具有访问所述目标api类对应的代码仓库的权限,则执行所述根据所述目标api的代码仓库,确定出接口描述文件的步骤。
31.第二方面,本发明提供一种api类生成装置,包括:
32.获取模块,用于获取目标api的后端处理请求;
33.第一确定模块,用于根据所述目标api的代码仓库,确定出接口描述文件;
34.第二确定模块,用于对所述接口描述文件进行解析,确定出api文档;
35.生成模块,用于基于所述接口描述文件,生成多个操作系统下的api类数据。
36.第三方面,本发明提供一种电子设备,包括:处理器、存储器,所述存储器存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述机器可读指令被所述处理器执行时执行如前述实施方式任一所述的方法的步骤。
37.第四方面,本发明提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如前述实施方式任一所述的方法的步骤。
38.本技术实施例的有益效果是:通过获得需要处理目标api的代码仓库,则可以自动生成api文档,以及进一步地生成api类,可以减少相关前端开发和后端开发的工作流程所需耗时,提高开发效率。另外,由于流程自动化,也可以降低人为误差,提高api文档、api类的准确性。
附图说明
39.为了更清楚地说明本技术实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本技术的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这
些附图获得其他相关的附图。
40.图1为本技术实施例提供的api类生成方法的运行环境示意图;
41.图2为本技术实施例提供的api类生成方法的流程图;
42.图3为本技术实施例提供的api类生成装置的功能模块示意图。
具体实施方式
43.下面将结合本技术实施例中附图,对本技术实施例中的技术方案进行描述。
44.应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。同时,在本技术的描述中,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
45.名词解释:
46.api文档:对api接口的请求方式、请求参数、调用参数或调用涉及到的参数等内容进行解释的文档。该api文档的呈现形式可以是网页形式,也可以是文件的形式。
47.客户端api类:根据api的结构,编写的ios或者安卓操作系统供实例化和运行的类或模型。
48.api mock数据:为了调试客户端或者web页面,模拟出的与接口数据结构和数据类型一致的数据。
49.常规的研发工作流是:在需求和技术方案确定后,web和客户端等前端开发都依赖后端开发提供的接口的数据结构,后端开发中通常要手动维护一份api文档以供展示。但是目前的常规研发流程通常存在三个痛点:
50.1)、api文档要手动编写,且长期积累下来的手动编写的文档相对无条理,不方便查看和维护;
51.2)、在以移动端为业务的团队中,ios或者安卓开发需要根据数据结构编写大量api的类模型,这类工作费时,浪费人力资源;
52.3)、生成的api文档中,通常没有mock数据,需要开发人员手动填写到代码中,实现起来相对比较耗时、效率较低。
53.基于上述现状,本技术提供了一种api类生成方法,能够无需手动编写api类,在后端开发进行git push操作后,就能自动生成客户端api类以及api文档。下面通过一些实施例提对本技术的api类生成方法进行描述。
54.为便于对本实施例进行理解,首先对执行本技术实施例所公开的一种api类生成方法的运行环境进行介绍。
55.如图1所示,是本技术实施例提供的api类生成方法的运行环境示意图。api类生成方法的运行环境可以包括:后台服务器110和第一终端设备120。
56.该后台服务器110通过网络与一个或多个第一终端设备120进行通信连接,以进行数据通信或交互。该后台服务器110可以是网络服务器、数据库服务器等。该第一终端设备120可以是个人电脑(personal computer,pc)、平板电脑、智能手机、个人数字助理(personal digital assistant,pda)等。
57.该第一终端设备120中可以提供有操作界面,该操作界面可以提供可以使用的后端开发所需的应用的操作窗口。示例性地,该操作界面可以是文档网站提供的界面。示例性
地,该操作窗口可用于接收目标代码仓库的地址,以使后台服务器110将目标代码仓库与后端开发所需的应用关联起来。后台服务器110还可以基于代码仓库与后端开发的应用的关联关系为各个代码仓库配置对应的用户账号。该用户账号的权限可以根据代码仓库与后端开发的应用的关联关系确定。
58.该后台服务器110可以用于提供api配置相关服务。例如,可以通过响应第一终端设备120中可以提供有操作界面提交的请求,以提供api配置相关服务。
59.可选地,该第一终端设备120中可以存放有api代码仓库。该后台服务器110可以链接到该第一终端设备120的api代码仓库的web hook,以克隆该第一终端设备120的api代码仓库。
60.下面通过一些实例来描述能够在上述运行环境中实现的api类生成方法。
61.请参阅图2,是本技术实施例提供的api类生成方法的流程图。本实施例的方法可以应用于提供包括api类生成服务的后台服务器。下面将对图2所示的具体流程进行详细阐述。
62.步骤210,获取目标api的后端处理请求。
63.可选地,该后端处理请求中可以携带该目标api的代码仓库的地址。
64.可选地,在api完成编写后,第一终端设备可以通过执行git push函数,以触发钩子函数hook。通过该钩子函数hook访问提供api配置服务的后台服务器。
65.示例性地,该钩子函数被触发后,后台服务器可以获取目标api的后端处理请求。
66.为了提高代码仓库的安全性,也提高对api的后端处理请求的可管理性,在获得后端处理请求后,可以在后台服务器对目标api对应的代码仓库进行操作之前,代码仓库所在终端可以对后台服务器的服务账号的权限进行验证,得到验证结果。
67.示例性地,该后台服务器的服务账号可以提前被目标api对应的代码仓库所在终端存储,并为该服务账号设置管理员权限,以使该后台服务器的服务账号能够访问目标api对应的代码仓库,并对该目标api对应的代码仓库进行克隆。
68.可选地,该目标api对应的代码仓库所在终端还可以设置该服务账号的服务时限,在该服务时限内,该后台服务器才能够使用该服务账号的管理员权限。
69.若所述验证结果表征后台服务器具有代码仓库的管理员权限时,再进行后续的步骤。
70.可选地,代码仓库所在终端可以对用户账号以及该用户账号的密码进行验证。
71.在一个实例中,若对服务账号的验证结果为验证失败,可以向用于管理目标api的代码仓库的管理账号发送验证失败的提示消息,还可以向后台服务器提供的服务的相关管理员账号发送验证失败的提示消息。验证失败原因可以是账号无效,也可以是该服务账号的权限不包括当前请求的服务,还可以是该服务账号已过期等。
72.步骤220,根据所述目标api的代码仓库,确定出接口描述文件。
73.示例性地,该目标api的代码仓库可以根据后端处理请求中的代码仓库的地址获得该目标api的代码仓库。
74.可选地,可以对目标api的代码仓库中的代码进行编译,可以生成接口描述文件。
75.该接口描述文件可以采用接口描述语言(interface description language,缩写idl)描述,例如,可以是swagger。
76.在一可选的实施方式中,步骤220可以包括:步骤221和步骤222。
77.步骤221,克隆所述目标api的代码仓库。
78.示例性地,可以通过与后端处理请求中所携带的代码仓库的地址与目标api的代码仓库建立链接,并对该目标api的代码仓库进行克隆,以得到该目标api的代码仓库。
79.可选地,可以根据后端处理请求中的代码仓库的地址找到代码仓库。
80.示例性地,代码仓库中可以包括可执行的脚本,还可以包括一些辅助文件。例如,该辅助文件可以是类模板文件,该类模板文件中可以包括一些可多次复用的模板,该类模板文件中被填充api类后,可以形成api类文件。
81.若该代码仓库使用本实施例中的api类生成方法操作过,则该代码仓库中还可以包括更新后的api类文件。因此,随着代码仓库被操作的次数越多,该代码仓库中的api类文件的数量也可能更多。
82.步骤222,通过编译工具,编译所述代码仓库中的代码,生成接口描述文件。
83.示例性地,可以调用该后台服务器中的编译工具,编译目标api的代码仓库中的代码。
84.可选地,该编译工具可以是marven工具。
85.可选地,若未编译成功,可以向用于管理目标api的代码仓库的管理账号发送未编译成功提示消息,还可以向后台服务器提供的服务的相关管理员账号发送未编译成功的提示消息。
86.步骤230,对所述接口描述文件进行解析,确定出api文档。
87.该api文档中记录的内容可以包括:目标api的请求方式、目标api的请求参数、目标api的调用方式、调用目标api所需参数等信息;该api文档中记录的内容还可以包括对目标api的使用规范的解释内容。
88.该api文档可以以网页形式呈现,也可以以其它格式的文件形式呈现。具体可以根据实际需求选择该api文档的呈现方式。
89.可选地,在步骤230之后,还可以将该api文档传输给第一终端设备。该第一终端设备可以在文档网站中显示该api文档,供相关技术人员查看。
90.可选地,若对所述接口描述文件解析失败,可以向用于管理目标api的代码仓库的管理账号发送解析失败的提示消息,还可以向后台服务器提供的服务的相关管理员账号发送解析失败的提示消息。
91.步骤240,基于所述接口描述文件,生成多个操作系统下的api类数据。
92.可选地,步骤240可以包括步骤241和步骤242。
93.步骤241,确定出多个操作系统下的代码仓库集。
94.示例性地,该代码仓库集中包括各个操作系统下的代码仓库。例如,该代码仓库中可以包括ios操作系统对应的代码仓库,还可以包括安卓操作系统对应的代码仓库。
95.在一可选的实施方式中,步骤241可以包括步骤2411和步骤2412。
96.步骤2411,获取所述多个操作系统下的配置参数。
97.示例性地,可以通过钩子函数hook调用url上配置的配置参数。
98.该配置参数可以包括各个操作系统下的api类代码的参数。示例性地,该配置参数用于指示是否需要生成各个操作系统下的api类。在该配置参数表征需要生成一操作系统
下的api类,则可以继续执行步骤2412,以生成该操作系统下的api类。
99.步骤2412,根据所述多个操作系统下的配置参数,确定出所述多个操作系统下的代码仓库集。
100.示例性地,每一操作系统可以对应一项配置参数,可以根据每一项操作系统对应的配置参数确定出是否需要生成对应操作系统下的api类。
101.示例性地,获得的配置参数也可以仅包括需要生成api类的操作系统对应的配置参数。
102.示例性地,基于配置参数确定需要生成ios操作系统的api类时,则可以克隆代码仓库中的ios代码仓库,以得到ios代码仓库。
103.示例性地,基于配置参数确定需要生成安卓操作系统的api类时,则可以克隆代码仓库中的安卓代码仓库,以得到安卓代码仓库。
104.可选地,在需要使用代码仓库集时,克隆预先确定出的多个操作系统下的代码仓库集。
105.每个代码仓库中可以包括一些模板文件。
106.示例性地,可以根据配置参数确定出需要形成api类的目标操作系统下的代码仓库。
107.在一个实例中,目标操作系统可以是ios操作系统,也可以是安卓操作系统。
108.可选地,可以从代码仓库中克隆目标操作系统的代码仓库。
109.步骤242,根据所述代码仓库集中各个代码仓库匹配的执行脚本,确定出多个操作系统下的api类数据。
110.该api类数据可以为api类文件,不同使用场景中或不同需求下该api类文件的形成方式不同。该api类文件可以是通过执行脚本,解析接口描述文件直接生成所需的api类文件;该api类文件也可以是通过执行脚本,解析接口描述文件生成api类,再将api类填充至类模板文件中,形成api类文件。
111.在一种实施方式中,该api文件可以通过执行脚本,对以解析接口描述文件,根据解析得到的接口内容和不同操作系统下的语法规则,生成api文件。
112.在另一种实施方式中,该api文件可以通过执行脚本,对以解析接口描述文件,根据解析得到的接口内容和不同操作系统下的语法规则,生成api类,并将该api类填充至类模板文件中,以形成api类文件。
113.可选地,各个api类文件可以存放在各个类文件夹中。
114.该类文件夹可以是通过目标api所包含的接口名称确定。示例性地,该目标api所包含的接口的数量可以为一个或多个。该目标api所包含的接口的数量在不同的使用场景中可能不同,也就是该类文件夹中的子文件夹的数量也可能由于使用场景的不同而不同。
115.在一个实例中,多个操作系统包括:ios操作系统和安卓操作系统。代码仓库中可以包括ios代码仓库和安卓代码仓库。步骤242可以包括:步骤2421和步骤2422。
116.步骤2421,使用所述代码仓库集中的ios操作系统的代码仓库对应的ruby脚本,执行所述ios操作系统的代码仓库中的模板文件,得到ios操作系统下的第一api类数据。
117.该第一api类数据可以是第一api类文件,该第一api类文件中可以包括第一api类。
118.示例性地,可以先克隆ios代码仓库,执行ios代码仓库中的ruby脚本,以解析接口描述文件,根据解析得到的接口内容和ios语法规则,生成第一目标文件,该第一目标文件可以是pod文件。
119.可选地,还可以根据解析得到的接口名生成第一文件夹,该第一目标文件可存放在第一文件夹中。
120.该第一目标文件则为第一api类文件,该第一api类文件中包括第一api类。
121.本实施例中,该第一目标文件可以是执行ios代码仓库中的ruby脚本,以解析接口描述文件,根据解析得到的接口内容和ios语法规则,直接生成的第一目标文件。该第一目标文件可以是执行ios代码仓库中的ruby脚本,以解析接口描述文件,根据解析得到的接口内容和ios语法规则,生成的第一api类,然后将该第一api类填充至ios代码仓库中的类模板文件得到的第一目标文件。
122.本实施例中,该第一文件夹中还可以包括多个子文件夹。该第一文件夹中的文件夹的数量可能会因为实际使用场景不同而不同。
123.在一个实例中,应用于电影票业务中,则电影票业务提供的服务系统中有多个服务组,例如,交易服务组、订单服务组、导购服务组,则在此应用场景中第一文件夹中可以包括三个子文件夹,分别表示交易服务组、订单服务组、导购服务组所需的文件夹,每个子文件夹中还可以分组,例如,交易服务组中对应的子文件夹中有两个文件夹,第一个是下单对应的文件夹,第二个是查订单所对应的文件夹,在该下单对应的文件夹和查订单所对应的文件夹的两个文件夹里中可以包括多个第一api类文件。
124.步骤2422,使用所述代码仓库集中的安卓操作系统的代码仓库对应的shell脚本,执行所述安卓操作系统的代码仓库中的模板文件,得到安卓操作系统下的第二api类数据。
125.该第二api类数据可以是第二api类文件,该第二api类文件中可以包括第二api类。
126.示例性地,可以先克隆安卓代码仓库,执行安卓代码仓库中的shell脚本,以解析接口描述文件,根据解析得到的接口内容和java语法规则,生成第二目标文件,该第二目标文件可以是jar包。
127.可选地,还可以根据解析得到的接口名生成第二文件夹,该第二目标文件可存放在第二文件夹中。
128.该第二目标文件可以是第二api类文件,该第二api类文件中包括第二api类。
129.该第二api类文件可以是执行安卓代码仓库中的shell脚本,以解析接口描述文件,根据解析得到的接口内容和java语法规则,直接生成的第二目标文件;该第二api类文件可以是执行安卓代码仓库中的shell脚本,以解析接口描述文件,根据解析得到的接口内容和java语法规则,生成的第二目标类,该第二目标类填充至安卓代码仓库中的类模板文件得到的第二目标文件。
130.示例性地,该第二文件夹中可以包括多个子文件夹,其中,该子文件夹的数量可以根据使用场景不同而不同。
131.可选地,可以将填充api类的代码仓库发送至代码仓库。示例性地,可以通过git push操作将填充api类的代码仓库发送给代码仓库。
132.可选地,后台服务器还可以与文档网站通信,该文档网站可以获得生成的类文件
夹。
133.该文档网站中可以提供一些显示界面,该显示界面可以显示接收到的类文件夹。
134.该类文件夹可以包括多个子文件夹。不用使用场景下的文件夹中所包含的文件夹的数量可以不同,具体可以按照使用场景所需的功能确定。
135.基于上述步骤210和步骤240,可以通过后台服务器提供的服务,在获知api的代码仓库后,则可以自动化生成api文档和api类。为了更好地实现对各个api对应的应用程序进行调试,且减少相关人员手动编写调试用的模拟接口数据的编写工作,还可以基于当前的api文档得到模拟接口数据。
136.在此需求下,在步骤240之后,api类生成方法,还可以包括:步骤250和步骤260。
137.步骤250,根据所述api文档,确定出目标应用服务组和目标api信息。
138.目标应用服务组可以包括目标api对应的应用程序所对应的服务。
139.可以基于该api文档种记录的解释内容,确定出目标api对应的应用程序所包含的服务,以及目标api对应的应用程序所包含的api。
140.步骤260,根据所述目标应用服务组和所述目标api,生成模拟接口数据。
141.该模拟接口数据用于调试所述目标api对应的目标客户端。
142.在一个实例中,该模拟接口数据可以是api mock数据。
143.可选地,还可以将生成的模拟接口数据传输给第一终端设备。该第一终端设备接收到该模拟接口数据后,可以在文档网站的显示界面中显示。
144.可选地,该第一终端设备还可以使用该模拟接口数据进行相关测试。
145.基于上述步骤210和步骤260,可以通过后台服务器提供的服务,在获知api的代码仓库后,则可以自动化生成api文档和api类。为了更好地实现对各个api代码仓库进行管理,可以在使用后台服务器提供的服务之前,先基于需求分配用户账号,以及为用户账号分配使用权限。
146.基于此,在步骤220之前,还可以包括:步骤270和步骤280。
147.步骤270,向所述目标api的代码仓库所在终端发送后台服务器的服务账号。
148.以供所述目标api的代码仓库所在终端为该服务账号分配权限,以使后台服务器能够对该目标api的代码仓库进行操作。该目标api的代码仓库所在终端为该服务账号分配权限后,可以将该服务账号存储在本地。以方便后台服务器访问该目标api的代码仓库时,对该服务账号进行验证。
149.示例性地,该服务账号的权限可以是管理员权限。
150.若所述验证结果表征所述服务账号具有访问所述目标api类对应的代码仓库的权限,则执行所述根据所述目标api的代码仓库,确定出接口描述文件的步骤。
151.在本技术实施例提供的api类生成方法中,通过获得需要处理目标api的代码仓库,则可以自动生成api文档,以及进一步地生成api类,通过工程化自动化的方式让设计好的系统服务去做重复机械的客户端api类编写,可以减少相关前端开发和后端开发的工作流程所需耗时,提高开发效率。另外,由于流程自动化,也可以降低人为误差,提高api文档、api类的准确性。
152.进一步地,基于git操作串联起了前端开发工作的内容,以及后端api文档生成的工作流,以使各开发环节能够形成了一体化的解决方案的工作流,且具备高扩展性。进一步
地,基于不同的需求可以配置多个可以访问后端处理服务的用户账号,以使更多用户能够使用该后端服务。
153.进一步地,本技术实施例中,可以丰富了文档网站的功能,能够灵活地配置mock数据,也能够自动生成mock数据,也就能够减少相关人员所需的工作量,也能够mock数据的形成效率。
154.基于同一申请构思,本技术实施例中还提供了与api类生成方法对应的api类生成装置,由于本技术实施例中的装置解决问题的原理与前述的api类生成方法实施例相似,因此本实施例中的装置的实施可以参见上述方法的实施例中的描述,重复之处不再赘述。
155.请参阅图3,是本技术实施例提供的api类生成装置的功能模块示意图。本实施例中的api类生成装置中的各个模块用于执行上述方法实施例中的各个步骤。api类生成装置包括:获取模块310、第一确定模块320、第二确定模块330、生成模块340;其中,
156.获取模块310,用于获取目标api的后端处理请求;
157.第一确定模块320,用于根据所述目标api的代码仓库,确定出接口描述文件;
158.第二确定模块330,用于对所述接口描述文件进行解析,确定出api文档;
159.生成模块340,用于基于所述接口描述文件,生成多个操作系统下的api类数据。
160.一种可能的实施方式中,第一确定模块320,用于:
161.克隆所述目标api的代码仓库;
162.通过编译工具,编译所述代码仓库中的代码,生成接口描述文件。
163.一种可能的实施方式中,生成模块340,包括:模板确定单元和类确定单元。
164.模板确定单元,用于确定出多个操作系统下的代码仓库集;
165.类确定单元,用于根据所述代码仓库集中各个代码仓库匹配的执行脚本,确定出多个操作系统下的api类数据。
166.一种可能的实施方式中,所述多个操作系统包括:ios操作系统和安卓操作系统;类确定单元,用于:
167.使用所述代码仓库集中的ios操作系统的代码仓库对应的ruby脚本,执行所述ios操作系统的代码仓库中的模板文件,得到ios操作系统下的第一api类数据;
168.使用所述代码仓库集中的安卓操作系统的代码仓库对应的shell脚本,执行所述安卓操作系统的代码仓库中的模板文件,得到安卓操作系统下的第二api类数据。
169.一种可能的实施方式中,模板确定单元,用于:
170.获取所述多个操作系统下的配置参数;
171.根据所述多个操作系统下的配置参数,确定出所述多个操作系统下的代码仓库集。
172.一种可能的实施方式中,所述代码仓库集中的各个代码仓库中包括类模板文件;类确定单元,还用于根据所述代码仓库集中各个代码仓库匹配的执行脚本,确定出多个操作系统下的api类;将所述多个操作系统下的api类,填充至各个操作系统下的类模板文件中,以形成api类文件。
173.一种可能的实施方式中,api类生成装置还可以包括:
174.第四确定模块,用于根据所述api文档,确定出目标应用服务组和目标api信息;
175.生成模块,用于根据所述目标应用服务组和所述目标api,生成模拟接口数据,所
述模拟接口数据用于调试所述目标api对应的目标客户端。
176.一种可能的实施方式中,应用于后台服务器,api类生成装置还可以包括:
177.验证模块,用于向所述目标api的代码仓库所在终端发送后台服务器的服务账号,以供所述目标api的代码仓库所在终端对所述服务账号的权限进行验证,得到验证结果;
178.若所述验证结果表征所述服务账号具有访问所述目标api类对应的代码仓库的权限,再执行上述的第一确定模块320。
179.此外,本技术实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述方法实施例中所述的api类生成方法的步骤。
180.本技术实施例所提供的api类生成方法的计算机程序产品,包括存储了程序代码的计算机可读存储介质,所述程序代码包括的指令可用于执行上述方法实施例中所述的api类生成方法的步骤,具体可参见上述方法实施例,在此不再赘述。
181.在本技术所提供的几个实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,附图中的流程图和框图显示了根据本技术的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
182.另外,在本技术各个实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。
183.所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-only memory)、随机存取存储器(ram,random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括
……”
限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
184.以上所述仅为本技术的优选实施例而已,并不用于限制本技术,对于本领域的技
术人员来说,本技术可以有各种更改和变化。凡在本技术的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本技术的保护范围之内。应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
185.以上所述,仅为本技术的具体实施方式,但本技术的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本技术揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本技术的保护范围之内。因此,本技术的保护范围应以权利要求的保护范围为准。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1