基于图谱的API编排方法及系统、电子设备、存储介质

技术领域

本申请涉及API编排技术领域，尤其涉及一种基于图谱的API编排方法及系统、电子设备、存储介质。

背景技术

在微服务架构中，存在着多种业务功能模块，而每一个模块都会对外暴露独立的应用程序编程接口(Application Programming Interface，API)。随着业务模块越来越多，功能越来越复杂，会将功能独立的模块封装成基础API，复杂业务功能模块则需要调用多个基础的API进行聚合处理，以此复用已有功能，开发新业务功能。

然而随着系统不断沉淀，基础API可能会非常多，API之间的依赖关系往往会非常复杂，每一个业务功能模块都会重复保存多个基础API的依赖，并且重写API之间的依赖调用导致大量重复的开发工作，同时也不方便API之间的依赖管理。

发明内容

有鉴于此，本申请提供一种基于图谱的API编排方法及系统，该编排方法将原子API与各个原子API之间的依赖关系构建成API图谱，将API编排转换成基于API图谱的查询服务，减少重复的开发工作且降低了API管理的复杂度。

为解决上述技术问题，本申请采用以下技术方案：

根据本发明实施例提供一种基于图谱的API编排方法，所述方法包括：

将独立功能模块封装成API，并对外暴露服务；

将若干所述API与所述若干所述API之间的依赖关系构建成第一API图谱，并保存为可通过三元组描述的图谱结构；

根据业务功能模块的需求，从所述第一API图谱中进行查询并选取，得到第二API图谱；其中，所述第二API图谱为所述第一API图谱的子集或全集；

对选取的所述第二API图谱利用图查询语言编写图谱查询语句，以应用于所述业务功能模块。

优选地，所述对选取的所述第二API图谱利用图查询语言编写图谱查询语句之后，还包括：

利用所述图查询语言对所述第二API图谱进行查询；其中，所述图查询语言至少包括SPARQL、Cypher和Gremlin中的一种。

优选地，所述利用所述图查询语言对所述第二API图谱进行查询之后，还包括：

计算编写好的所述图查询语句的输出结果，以确定所述图谱查询语句匹配所述业务功能模块的需求。

优选地，所述保存为可通过三元组描述的图谱结构，包括：

将所述第一API图谱保存成RDF文档。

优选地，所述根据业务功能模块的需求，从所述第一API图谱中进行查询并选取，得到第二API图谱，包括：

根据所述业务功能模块的需求，从所述第一API图谱中进行查询并选取需要依赖的若干所述API，若干所述API以及所述若干所述API之间的依赖关系形成所述第二API图谱。

本发明还提供一种基于图谱的API编排系统，包括：

封装模块，被配置用于将独立功能模块封装成API，并对外暴露服务；

构建模块，被配置用于将若干所述API与各个所述API之间的依赖关系构建成第一API图谱，并保存为可通过三元组描述的图谱结构；

选取模块，被配置用于根据业务功能模块的需求，从所述第一API图谱中进行查询并选取，得到第二API图谱；其中，所述第二API图谱为所述第一API图谱的子集或全集；

编写模块，被配置用于对选取的所述第二API图谱利用图查询语言编写图谱查询语句，以应用于所述业务功能模块。

优选地，还包括：

查询模块，被配置用于利用所述图查询语言对所述第二API图谱进行查询；其中，所述图查询语言至少包括SPARQL、Cypher和Gremlin中的一种。

优选地，还包括：

计算模块，被配置用于计算编写好的所述图谱查询语句的输出结果，匹配所述业务功能模块的需求。

优选地，所述选取模块包括选取单元；

所述选取单元，被配置用于根据所述业务功能模块的需求，从所述第一API图谱中进行查询并选取需要依赖的若干所述API，若干所述API以及所述若干所述API之间的依赖关系形成所述第二API图谱。

本发明实施例还提供一种电子设备，所述电子设备包括：

处理器；

存储器；以及程序，其中，所述程序被存储在所述存储器中，并且被配置成由处理器执行，以使得所述电子设备实现所述一种基于图谱的API编排方法。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序：所述计算机程序被处理器执行实现所述一种基于图谱的API编排方法。

本申请的上述技术方案至少具有如下有益效果之一：

根据本申请实施例的一种基于图谱的API编排方法及系统，该编排方法将原子API以及各个原子API之间的依赖关系构建成API图谱，根据业务功能需求从构建的API图谱中进行选取需要依赖的原子API，并进行编写；该方法将API编排转换成基于API图谱的查询服务即复用了原子API的功能，也复用了原子API之间的依赖关系，减少了重复开发的工作量；将众多原子API以及各个原子API之间的依赖关系构建成API图谱，且使用的图谱是提前构建完成的，降低了数量较多的原子API的复杂度，提高了对众多原子API的管理的便捷性。

附图说明

图1为本申请实施例的API图谱的结构示意图；

图2为本申请实施例的基于图谱的API编排方法的整体流程图；

图3为本申请实施例的基于图谱的API编排方法的具体流程图；

图4为本申请具体实施例中需要获取的歌曲列表示意图；

图5为本申请具体实施例中获取歌曲列表的后端的API图谱的逻辑示意图；

图6为本申请实施例的基于图谱的API编排系统的模块图。

附图标记：

1、歌曲列表，10、封装模块，20、构建模块，30、选取模块，310、选取单元，40、编写模块，50、查询模块，60、计算模块，100、第一API图谱，200、第二API图谱。

具体实施方式

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

下面对本申请中的技术术语进行说明。

应用程序编程接口(Application Programming Interface，API)是一些预先定义的函数，或指软件系统不同组成部分衔接的约定。用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。API的基本信息包括访问协议、入参和出参；其中，入参即为输入字段及字段类型，出参即为输入字段及字段类型。

在现有技术中，随着业务的发展，基于业务功能模块的维度，组合、管理原子模块的API，依然存在很多问题。比如：每个业务功能模块都需要保存一份API的依赖关系，尽管多个模块都会重复这些API；每个业务功能模块都需要独立完成所需API之间的依赖调用逻辑，常常导致在API编排中出现大量重复的API调用逻辑；基于业务功能模块维度编排API，以至于不能从全局的角度分析API之间的关系，导致无法快速的查询所需要的原子API。

针对现有技术存在的上述问题，本申请提供的基于图谱的API编排方法，将若干API与若干API之间的依赖关系构建成API图谱，并保存为可通过三元组描述的图谱结构，根据业务功能需求从构建的API图谱中进行选取需要依赖的原子API，并利用图查询语言进行编写；由于在前期已经确定了各API之间的依赖关系以及API调用逻辑，因此API之间的依赖调用可由系统统一完成，业务功能模块只需要提供简单的图查询语言(比如：SPARQL)，即可完成多个API的编排。该方法将API编排转换成基于API图谱的查询服务，即复用了原子API的功能，也复用了原子API之间的依赖关系，减少了重复开发的工作量；将众多原子API以及各个原子API之间的依赖关系构建成API图谱，且使用的图谱是提前构建完成的，降低了数量较多的原子API的复杂度，提高了对众多原子API管理的便捷性。

下面通过结合具体的附图对本申请的各个实施例进行详细的说明。

图1为本申请一实施例提供的基于图谱的API编排方法中的图谱的结构示意图。如图1所示，图1中显示的第一API图谱100的顶点即为一个API，每一条边即为两个API之间的依赖关系，图谱中包括若干个API以及若干个API之间的依赖关系。

本申请的一个实施例中提供一种基于图谱的API编排方法，该API编排方法由电子设备执行，如图2所示，具体包括如下步骤：

S1、将独立功能模块封装成API，并对外暴露服务。

将能实现某一功能的模块封装成API即应用编程接口，该应用编程接口是一组定义、程序及协议的集合，一般API使用http协议对外暴露服务，当然不限定只使用http协议。

S2、将若干API与若干API之间的依赖关系构建成第一API图谱，并保存为可通过三元组描述的图谱结构。优选地将第一API图谱保存为RDF文档，资源描述框架(ResourceDescription Framework，RDF)。RDF是一种描述资源的方式，RDF的每一条描述都是一个主谓宾三元组构成的短句。API作为第一API图谱的顶点，若干API之间的依赖关系为第一API图谱的边。相邻的API之间的依赖关系包括起点API的出参与终点API的入参之间的关系。比如：endApi.in.id＝startApi.out.name，表示尾顶点的入参中的id字段，需要由起始顶点的输出字段name传递。

S3、根据业务功能模块的需求，从第一API图谱中进行查询并选取，得到第二API图谱200；其中，第二API图谱200为第一API图谱100的子集或全集。根据业务需求从步骤S2中构建的第一API图谱中查询得到与其匹配的第二API图谱，第二API图谱可以与第一API图谱相同，也可以是第一API图谱的子集。业务功能模块的需求可以理解为：根据业务需求，现在需要开发新的应用程序，在开发的过程中，在步骤S2中构建的第一API图谱中查询跟业务需求匹配的第二API图谱，并获取匹配的第二API图谱，用于新的应用程序的开发。第二API图谱中包括若干API以及若干API之间的依赖关系，在开发新的应用程序的过程中可直接调用前期确定好的API之间的依赖关系以及调用逻辑，故在新的应用程序的开发中API之间的依赖调用，可由系统统一完成，减少了重复开发的工作，且降低了复杂度。

具体地，根据业务功能模块的需求，从第一API图谱中进行查询并选取需要依赖的若干API，若干API以及若干API之间的依赖关系形成第二API图谱。应当理解为：根据业务的需求从第一API图谱中优先进行查询所需的API，以及API之间的依赖关系，将所需的API与API之间的依赖关系进行选取形成第二API图谱。S4、对选取的第二API图谱利用图查询语言编写图谱查询语句，以应用于业务功能模块。从前期构建的第一API图谱中选取得到第二API图谱，第二API图谱将应用于新的应用程序开发中，在第二API图谱应用于新的应用程序开发中之前，利用图查询语言对第二API图谱编写图谱查询语句，以匹配新的应用程序开发中。

本申请的一个实施例中，如图3所示，在步骤S4之后还包括步骤：

S5、利用图查询语言对第二API图谱进行查询；其中，所述图查询语言至少包括SPARQL、Cypher和Gremlin中的一种。利用图查询语言查询第二API图谱，得到若干API信息以及若干API之间的依赖调用信息。SPARQL的英文全称为SPARQL Protocol and RDF QueryLanguage，是为RDF开发的一种查询语言和数据获取协议，可以用于任何可以用RDF来表示的信息资源。Cypher是一个描述性的图形查询语言，允许不必编写图形结构的遍历代码对图形存储有表现力和效率的查询。Gremlin是一种函数式数据流语言，可使得用户使用简洁的方式表述复杂的属性图的遍历或查询。

本申请的一个实施例中，在步骤S5之后还包括步骤：

S6、计算编写好的图查询语句的输出结果，以确定图谱查询语句匹配业务功能模块的需求。计算步骤S4中编写的图查询语句的业务逻辑关系，通过计算确定通过图查询语言对图查询语句进行调试得出的输出结果，是否匹配业务功能模块的需求。在确认匹配后最终得到基于第二API图谱编写的图查询语句并应用于新的应用程序的开发中。

本申请实施例只需要根据业务功能模块的需求提供较为简单的图查询语言的编排，就可以根据前期构建好的第一API图谱编排完成若干个第二API图谱以应用于新的应用程序的开发，大大减小了重复开发的工作量。由于本申请实施例中的各个API之间的依赖关系是新应用程序开发前就已经构建成图谱的形式，故可以基于API图谱的方式进行管理若干个API，大大提高了管理数量较多的API的便捷性。

基于本申请上述实施例提供的方法，下面结合具体的例子进行进一步的说明。

具体地，如图4所示，图4中显示了部分获取的歌曲列表1信息示意图，获取歌曲列表作为业务需求，其中歌曲列表中包括歌曲的名称、歌曲的演唱者和专辑名称。获取图4中的歌曲列表的后端具有如下四个API：

1、通过用户标签查询歌曲ID列表：

get_music_records_by_tags；

2、通过歌曲ID获取歌曲详情，并获取演唱者即艺人的ID号、专辑ID：

get_music_records_details_by_id；

3、通过艺人ID号，获取艺人的名称信息：

get_arts_detail_by_id；

4、通过专辑ID号，获取专辑的名称信息：

get_collect_detail_by_id。

为了进一步突出本申请的技术方案，下面是通过现有技术中的方法与本申请中提供的方法分别通过代码进行说明。

利用现有技术中的传统方法的业务逻辑的伪代码如下：

下面是利用本申请中提供的API编排方法，具体如下：

根据业务需求，从前期构建好的图谱结构中选取需要依赖的API以及API之间的依赖关系，如图5所示。图5中的API_1为通过用户标签查询歌曲ID列表，即get_music_records_by_tags；API_2为通过艺人的ID号获取艺人的名称信息，即get_arts_detail_by_id；API_3为通过专辑ID号获取专辑的名称信息，即get_collect_detail_by_id；API_4为通过歌曲ID获取歌曲详情、艺人的ID号、专辑ID，即get_music_records_details_by_id。图5中显示了新的应用程序中所需要的图谱即第二API图谱200，图谱中包括四个API即API_1、API_2、API_3和API_4，以及四个API之间的依赖关系即API_1与API_2之间的依赖关系out.recodid＝in.id；API_4与API_3之间的依赖关系out.collectid＝in.id；API_4与API_2之间的依赖关系out.artistid＝in.id。

具体地，利用图查询语言对选取的图谱，即需要依赖的API以及API之间的依赖关系编写图谱查询语句，并进行查询，代码如下：

select recordName,artistName,collectName

from get_music_records_by_tags A

join get_music_records_details_by_id B ON A.recordId＝B.id

join get_arts_detail_by_id C ON B.artistId＝C.id

join get_collect_detail_by_id D ON B.collectId＝D.id

where A.tags＝"轻音乐，复古，唯美，帅哥"

；

上述代码是基于结构化查询语言(Structured Query Language，SQL)，因为SQL较为简便方便理解。SQL可替换为SPARQL、Grelline和Gremlin中的任意一种。

通过上述两种方式实现功能模块，可知利用本申请提供的方法实现由于在前期已经确定了各API之间的依赖关系以及API调用逻辑，因此API之间的依赖调用可由系统统一完成，业务功能模块只需要提供简单的图查询语言(比如：SPARQL)，即可完成多个API的编排。而在利用传统方式实现只能重复调用基础API并重写API之间的依赖关系。

本发明还提供一种基于图谱的API编排系统，如图6所示，包括封装模块10、构建模块20、选取模块30和编写模块40。

其中，封装模块10被配置用于将独立功能模块封装成API，并对外暴露服务；

构建模块20被配置用于将若干API与各个API之间的依赖关系构建成第一API图谱，并保存为可通过三元组描述的图谱结构；

选取模块30被配置用于根据业务功能模块的需求，从第一API图谱中进行查询并选取，得到第二API图谱；其中，第二API图谱为第一API图谱的子集或全集；

编写模块40被配置用于对选取的第二API图谱利用图查询语言编写图谱查询语句，以应用于业务功能模块。

在本发明的一实施例中，还包括查询模块50；

查询模块50被配置用于利用图查询语言对第二API图谱进行查询；其中，图查询语言至少包括SPARQL、Cypher和Gremlin中的一种。

在本发明的一实施例中，还包括计算模块60；

计算模块60被配置用于计算编写好的图谱查询语句的输出结果，匹配业务功能模块的需求。

在本发明的一实施例中，选取模块包括选取单元310；

选取单元310被配置用于根据业务功能模块的需求，从第一API图谱中进行查询并选取需要依赖的若干API，若干API以及若干API之间的依赖关系形成第二API图谱。

本发明实施例还提供一种电子设备，电子设备包括：处理器；存储器；以及程序，其中，程序被存储在存储器中，并且被配置成由处理器执行，以使得电子设备实现一种基于图谱的API编排方法。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序：计算机程序被处理器执行实现一种基于图谱的API编排方法。

需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者装置中还存在另外的相同要素。

以上所述是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请所述原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。