CN113901169A

CN113901169A - 信息处理方法、装置、电子设备及存储介质

Info

Publication number: CN113901169A
Application number: CN202111251793.0A
Authority: CN
Inventors: 杨磊
Original assignee: Lenovo Beijing Ltd
Current assignee: Lenovo Beijing Ltd
Priority date: 2021-10-25
Filing date: 2021-10-25
Publication date: 2022-01-07

Abstract

本申请提供的信息处理方法，通过获得目标API在低代码平台已发布应用下的业务特征，来确定该目标API与业务特征相匹配的标签。由于业务特征能够表征目标API所在的业务场景，因此确定的标签可以体现目标API在应用场景中的实际用途，由此可以在实际使用角度为API检索提供一种有效的信息检索途径。

Description

信息处理方法、装置、电子设备及存储介质

技术领域

本申请涉及软件技术领域，更具体地说，涉及一种信息处理方法、装置、电子设备及存储介质。

背景技术

API(Application Program 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与所述业务特征相匹配的标签。

经由上述的技术方案可知，本申请提供的信息处理方法，通过获得目标API在低代码平台已发布应用下的业务特征，来确定该目标API与业务特征相匹配的标签。由于业务特征能够表征目标API所在的业务场景，因此确定的标签可以体现目标API在业务场景中的实际用途，由此可以在实际使用角度为API检索提供一种有效的信息检索途径。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例提供的电子设备的硬件结构框图；

图2为本申请实施例提供的信息处理方法的方法流程图；

图3为本申请实施例提供的另一信息处理方法的方法流程图；

图4为本申请实施例提供的另一信息处理方法的方法流程图；

图5为本申请实施例提供的信息处理场景的场景示意图；

图6为本申请实施例提供的信息处理装置的结构示意图。

具体实施方式

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

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

为方便理解本申请，以下首先低代码平台中设计交互表单并绑定API的背景进行说明：

现阶段，一个应用，比如web应用的开发通常涉及到前端开发和后端开发：前端的美工设计应用产品原型，即前端页面中交互表单的图片，前端的开发人员编写大量的代码将交互表单的图片转换为html格式的浏览器能够识别的网页。此时，前端开发的网页并不具备交互能力，这就需要后端的开发人员编写大量的代码开发后端的程序(也可称为微服务)。

后端的程序能够执行复杂的业务逻辑运算，比如对数据库中的数据进行增删改查等操作。另外，为实现后端与前端的对接，后端的开发人员需要将后端的程序暴露为API，再由前端的开发人员将网页格式的交互表单与API进行绑定。对于每个应用来说，在其整个应用开发过程，都需要前后端开发人员开发编写大量的代码才能实现，开发过程繁琐、效率低、成本高。

对此，为简化开发，低代码平台中预先开发并封装大量的组件，组件可以被重复使用，通过拖拽组件的方式来实现应用开发。以前端设计交互表单为例，无需通过设计图和开发程序转换，前端的开发人员以一定的逻辑关系或者一定的设计布局通过拖拽交互表单相关的组件，比如输入框、下拉框或者长文本编辑框等就可完成交互表单的设计，这就可以将交互表单的开发时间由通常的一个星期降低为短短数个小时。当然，对于后端的程序开发、交互表单与API的绑定也同样以后端的开发人员拖拽组件的方式来实现。

后端的程序本质上是至少业务逻辑运算的代码，其需要通过API这种接口方式才能与前端对接。后端的程序开发数量极多时，需要暴露的API的也就极多，一个应用涉及数十个、甚至上百个API。对于前端的开发人员，其为交互表单绑定API，就需要从海量的API中检索所需的API，这就需要为API进行分类。而目前API分类往往依赖于后端的开发人员对于API的认知，后端的开发人员通过标签的方式为API增加特征描述，以形成API信息索引，以提高前端的开发人员检索API的效率。

研究发现，现有低代码技术主要有以下几种方法创建API标签：

1)通过API统一管理平台或知识文档中心，人工添加API分类标签，并通过反馈机制人工完善API标签分类。此方法高度依赖组织的API维护流程和维护人员的个人经验，由此信息会存在不准确和延迟的问题。

2)根据API自身属性自动生成API标签。此方法虽然减少了人工维护标签的过程，但依赖于后端的开发人员对API的属性定义，因此难免存在定义不准确或描述不全面等问题。

对应的，为补充现有API标签创建方法的不足，本申请提供一种信息处理方法。API一旦被投入生产使用，就基本确定了该API在对应业务场景(或应用领域)可用且具有使用价值，这种实际用途作为API的检索条件至关重要，由此本申请根据API已知用途自动生成API标签，用于API信息检索。

本申请提供的信息处理方法可以应用于电子设备，参见图1所示的电子设备的硬件结构框图，该电子设备的硬件结构可以包括：处理器11、通信接口12，存储器13和通信总线14；

在本申请实施例中，处理器11、通信接口12、存储器13、通信总线14的数量为至少一个，且处理器11、通信接口12、存储器13通过通信总线14完成相互间的通信。

处理器11可以是一个中央处理器CPU、GPU(Graphics Processing Unit，图形处理器)，或者是特定集成电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路等。

存储器13可以包括高速RAM存储器，也可以还包括非易失性存储器(non-volatilememory)等，例如至少一个磁盘存储器。

其中，存储器13存储应用程序及应用程序运行所产生的数据，处理器11则执行应用程序，以实现功能：

获得目标应用程序接口API在低代码平台已发布应用下的业务特征，业务特征用于表征目标API所在的业务场景；确定目标API与业务特征相匹配的标签。

需要说明的是，处理器执行应用程序所实现功能的细化和扩展，可以参见下文描述。

本申请实施例提供一种信息处理方法，参见图2所示的方法流程图，该方法包括如下步骤：

S101，获得目标应用程序接口API在低代码平台已发布应用下的业务特征，业务特征用于表征目标API所在的业务场景。

本申请实施例中，低代码平台通过拖拽组件可以生成应用的交互表单，并对该交互表单绑定合适的API以获得表单交互能力。通过应用发布，安装部署应用，应用可以在正式环境中启动，应用使用者可以使用该应用。

应用使用者在使用该应用的过程中，可以在前端的交互表单中选择特定的数据项，进而触发该交互表单调用其绑定的API，向该API发送所选择数据项对应的一组参数(该组参数是由前端的开发人员所设计)，由该API所对应的后台的程序则基于该组参数执行业务逻辑运算。以检索操作为例，后台的程序在数据库中检索该组参数对应的数据，由API将检索到的数据返回给前端，前端按照定义的形式进行展示，比如以列表或者图表的形式展示。由此，完成一个已发布应用前端与后端的交互。

对于低代码平台的一个已发布应用，其前端具有至少一个交互表单，而每个交互表单则绑定有至少一个API。对于API来说，其可以仅与某个已发布应用前端的交互表单相绑定，还可以与多个已发布应用前端的交互表单相绑定，而对于一个已发布应用来说，该API还可以与其前端的一个或多个交互表单相绑定。

为方便理解，举例来说明，低代码平台的已发布应用包括应用1和应用2，应用1的前端包括两个独立的交互表单1-1和1-2，应用2包括两个具有层级关系的交互表单2-1和2-2，其中，交互表单1-1绑定API1和API2、交互表单1-2绑定API2和API3、交互表单2-1绑定API1、API3和API4、交互表单2-2绑定API5。需要说明的是，API1、API2、API3、API4和API5可以属于同一类API，比如均为检索类API，而不同的API对应不同的数据项(或者前端的开发人员所设计的一组参数)，即不同的API可以对应的不同检索条件。

而目标API则可以为已发布应用前端的交互表单所绑定的任意一个API。以应用1为例，对于其前端的交互表单1-1所绑定API1来说，在其作为目标API时，可以对其进行如下接口分析：

首先，确定低代码平台已发布应用中前端的交互表单绑定API1的应用。由于低代码平台已发布应用中应用1前端的交互表单1-1绑定API1、应用2前端的交互表单2-1绑定API1，因此可以确定低代码平台已发布应用中其前端的交互表单绑定API1的应用包括应用1和应用2。

进一步，获得API1在应用1和应用2下的业务特征。由于业务特征用于表征API所在的业务场景，因此可以对API1在应用1中所涉及的业务场景、以及API1在应用2中所涉及的业务场景进行分析，以获得API1在应用1和应用2的业务特征。

在实际应用中，可以在低代码平台发布应用时，自动触发对该应用下的交互表单进行相关性分析，获取交互表单与API的关系，以构建交互表单与API的关系模型，该关系模型中记录有交互表单与API的绑定关系、以及交互表单间的层级关系。对此，对于一个已被指定的目标API，如果监测到低代码平台发布交互表单绑定有该目标API的应用，则执行“获得目标API在低代码平台已发布应用下的业务特征”的步骤。当然，在低代码平台发布应用时，可以将该应用下交互表单所绑定的各API分别作为目标API，以此分析各API的标签。

S102，确定目标API与业务特征相匹配的标签。

本申请实施例中，对于目标API的业务特征，可以利用分类算法对该业务特征进行分类处理，以确定相应的标签作目标API的标签。而分类算法所涉及的模型可以基于现有的机器学习的方式进行训练，在此不再赘述。

在其他一些实施例中，还可以将目标API的标签添加至已创建的标签库中，该标签库中记录有不同API的标签，其中一个API可以具有一个或多个标签，即一个API可以应用至一个或多个业务场景。前端的开发人员再为交互表单绑定API时，可以通过API检索引擎，以熟悉的业务场景或者业务对象关键字对标签库中的API进行检索，便很容易检索到相关的API。根据实际使用场景自动生成API标签库，减少了人工维护标签带来的信息准确性和及时性问题。

本申请实施例提供的信息处理方法，通过获得目标API在低代码平台已发布应用下的业务特征，来确定该目标API与业务特征相匹配的标签。由于业务特征能够表征目标API所在的业务场景，因此确定的标签可以体现目标API在业务场景中的实际用途，由此可以在实际使用角度为API检索提供一种有效的信息检索途径。

作为获得目标API在低代码平台已发布应用下的业务特征的一种实现方式，本申请实施例提供另一种信息处理方法，参见图3所示的方法流程图，该方法包括如下步骤：

S201，基于低代码平台在已发布应用下对目标API的拖拽操作，确定与目标API在已发布应用下相关联的资源对象。

本申请实施例中，低代码平台通过拖拽组件的方式即可完成实现应用开发，因此对于目标API，同样可以基于在已发布应用下对其的拖拽操作确定与其相关联的资源对象，该资源对象至少包括已发布应用下绑定该目标API的交互表单。

为方便理解，继续以上述举例来说明，继续以应用1为例，对于其前端的交互表单1-1所绑定API1来说，在其作为目标API时，可以基于低代码平台针对其的拖拽操作确定其在应用1和应用2下相关联的资源对象，该资源对象至少包括交互表单1-1和2-1。

S202，至少获得资源对象的业务描述，并从业务描述中提取业务特征，业务特征用于表征目标API所在的业务场景。

本申请实施例中，对于目标API，至少获得其资源对象的业务描述，该业务描述用于描述资源对象所在的业务场景。基于资源对象的业务描述，能够确定资源对象所在的业务场景，以此推断确定目标API的业务场景。

另外，在获得资源对象的业务描述后，可以从业务描述中提取表征业务场景的业务特征，具体的，可以从中提取表征业务场景的关键词，将所提取的关键词作为业务特征。

在其它一些实施例中，可以通过自然语言处理从业务描述中提取业务特征。具体的，可以对业务描述进行分词处理得到业务描述对应的词组，进一步对所获得的词组进行预处理，比如停用词去除，得到表征业务场景的关键业务特征。

当然，除业务描述之外，还可以获得资源对象的属性描述，该属性描述用于描述资源对象的属性，比如资源对象所涉及的字段。进而，基于资源对象的业务描述和属性描述来确定资源对象所在的业务场景。

S203，确定目标API与业务特征相匹配的标签。

本申请实施例提供的信息处理方法，能够基于低代码平台在已发布应用下对目标API的拖拽操作，来确定目标API在已发布应用下相关联的资源对象，从而至少通过该资源对象的业务描述提取目标API的业务特征，以此可以精确确定目标API在业务场景中的实际用途，补充现有API标签创建方法的不足。

作为确定与目标API在已发布应用下相关联的资源对象的一种实现方式，本申请实施例提供另一种信息处理方法，参见图4所示的方法流程图，该方法包括如下步骤：

S301，基于低代码平台在已发布应用下对目标API的拖拽操作，确定与目标API在已发布应用下具有绑定关系的第一交互表单，在第一交互表单、与第一交互表单具有层级关系的第二交互表单、以及第一交互表单所在的已发布应用中确定资源对象。

本申请实施例中，低代码平台通过拖拽组件的方式即可完成实现应用开发，因此对于目标API，同样可以基于在已发布应用下对其的拖拽操作确定与其相关联的资源对象，该资源对象可以从已发布应用下绑定该目标API的交互表单(即第一交互表单)、与第一交互表单具有层级关系的交互表单(即第二交互表单)、以及第一交互表单所在的已发布应用中确定，可以为三者中的任意一者或多者。

为方便理解，继续以上述举例来说明，继续以应用1为例，对于其前端的交互表单1-1所绑定API1来说，在其作为目标API时，可以基于低代码平台针对其的拖拽操作确定其在应用1和应用2下相关联的资源对象，该资源对象包括绑定API1的第一交互表单(即交互表单1-1和2-1)、与第一交互表单具有层级关系的第二交互表单(即交互表单2-2)、以及第一交互表单所在的已发布应用(即应用1和应用2)。

对此，API1作为目标API时，由于其分别被应用1前端的交互表单1-1、以及应用2前端的交互表单2-1所绑定，因此可以分别分析API1在应用1下的业务特征、以及在应用2下的业务特征。对于API1在应用1下的业务特征，可以从交互表单1-1和应用1中确定与API1相关联的资源对象；对于API1在应用2下的业务特征，则可以从交互表单2-1、交互表单2-2和应用2中确定API1相关联的资源对象。

S302，至少获得资源对象的业务描述，并从业务描述中提取业务特征，业务特征用于表征目标API所在的业务场景。

为方便理解，继续以上述举例说明，继续以应用1为例，对于其前端的交互表单1-1所绑定API1来说，在其作为目标API时，一方面可以从交互表单1-1和应用1中确定与API1相关联的资源对象来确定API1在应用1下的业务特征，另一方面可以从交互表单2-1、交互表单2-2和应用2中确定API1相关联的资源对象来确定API1在应用2下的业务特征。

假设，确定API1在应用1下的业务特征时的资源对象包括交互表单1-1和应用1，确定API1在应用2下的业务特征时的资源对象包括交互表单2-1、交互表单2-2和应用2。对此，一方面可以获得交互表单1-1和应用1的业务描述和属性描述，进一步从该业务描述和属性描述中提取API1在应用1下的业务特征，具体可以通能够该分词处理和预处理得到其中的关键业务特征；另一方面可以获得交互表单2-1、交互表单2-2和应用2的业务描述和属性描述，进一步从业务描述和属性描述中提取API1在应用2下的业务特征，具体可以通能够该分词处理和预处理得到其中的关键业务特征。

S303，确定目标API与业务特征相匹配的标签。

本申请实施例提供的信息处理方法，能够基于低代码平台在已发布应用下对目标API的拖拽操作，来确定目标API在已发布应用下相关联的交互表单和/或应用，从而至少通过相关联的交互表单和/或应用的业务描述提取目标API的业务特征，以此可以精确确定目标API在业务场景中的实际用途，补充现有API标签创建方法的不足。

参见图5所示的信息处理场景。低代码平台用户(前后端的开发人员)在低代码平台通过拖拽组件设计交互表单，选择并绑定合适的API以获得表单交互能力，最后通过发布应用，安装部署应用，在正式环境启动并使用低代码应用。

应用发布时，自动触发应用表单的相关性分析，获取交互表单与API的关系，以构建交互表单与API的关系模型。交互表单在创建和发布时，已为应用/交互表单添加业务描述和属性描述等便于后期维护，利用分词技术对业务描述和属性描述进行处理后得到应用/交互表单的关键业务特征。利用分类算法对应用/交互表单的关键业务特征进行分类处理得到相应的标签，结合交互表单与API的关系模型创建API的标签库。前端的开发人员再为交互表单绑定API时，可以通过API检索引擎，以熟悉的业务场景或者业务对象关键字对标签库中的API进行检索，便很容易检索到相关的API。

需要说明的是，在场景实施例中先获得应用/交互表单的业务描述和属性描述、再利用分词技术得到应用/交互表单的关键业务特征，进一步结合交互表单与API的关系模型确定API相关联的资源对象(应用和/或交互表单)，从而将资源对象的关键业务特征作为API的关键业务特征。上述信息处理方法实施例中先确定API相关联的资源对象、再利用分词技术对资源对象的业务描述和属性描述进行处理得到资源对象的关键业务特征，以此作为API的关键业务特征。两种实现方案在关键业务特征获得的时间有所区别，均在本申请的保护范围内。

与上述实施例提供的信息处理方法对应的，本申请实施例则提供一种信息处理装置，如图6所示，该信息处理装置包括：

特征获得模块10，用于获得目标应用程序接口API在低代码平台已发布应用下的业务特征，业务特征用于表征目标API所在的业务场景；

标签确定模块20，用于确定目标API与业务特征相匹配的标签。

在本申请公开的信息处理装置的另一实施例中，特征获得模块10，具体用于：

基于低代码平台在已发布应用下对目标API的拖拽操作，确定与目标API在已发布应用下相关联的资源对象；至少获得资源对象的业务描述，并从业务描述中提取业务特征。

在本申请公开的信息处理装置的另一实施例中，特征获得模块10确定与目标API在已发布应用下相关联的资源对象，包括：

确定与目标API在已发布应用下具有绑定关系的第一交互表单；在第一交互表单、与第一交互表单具有层级关系的第二交互表单、以及第一交互表单所在的已发布应用中确定资源对象。

在本申请公开的信息处理装置的另一实施例中，特征获得模块10从业务描述中提取业务特征，包括：

通过自然语言处理从业务描述中提取业务特征。

如果监测到低代码平台发布交互表单绑定有目标API的应用，则获得目标API在低代码平台已发布应用下的业务特征。

在本申请公开的信息处理装置的另一实施例中，标签确定模块20，还用于：

将目标API的标签添加至已创建的标签库中，标签库中的标签是进行API检索的依据。

本申请实施例中各模块的细化功能可以参见上述信息处理方法实施例对应公开部分，在此不再赘述。

与上述信息处理方法对应的，本申请还公开了一种存储介质，存储介质中存储有计算机可执行指令，计算机可执行指令用于执行：获得目标应用程序接口API在低代码平台已发布应用下的业务特征，业务特征用于表征目标API所在的业务场景；确定目标API与业务特征相匹配的标签。

以上对本申请所提供的一种信息处理方法、装置、电子设备及存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

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

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

1.一种信息处理方法，所述方法包括：

确定所述目标API与所述业务特征相匹配的标签。

2.根据权利要求1所述的方法，所述获得目标API在低代码平台已发布应用下的业务特征，包括：

3.根据权利要求2所述的方法，所述确定与所述目标API在已发布应用下相关联的资源对象，包括：

4.根据权利要求2所述的方法，所述从所述业务描述中提取所述业务特征，包括：

通过自然语言处理从所述业务描述中提取所述业务特征。

5.根据权利要求1所述的方法，所述获得目标API在低代码平台已发布应用下的业务特征，包括：

6.根据权利要求1所述的方法，所述方法还包括：

7.一种信息处理装置，所述装置包括：

8.根据权利要求7所述的装置，所述特征获得模块，具体用于：

9.一种电子设备，所述电子设备包括：

10.一种存储介质，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令用于执行：获得目标应用程序接口API在低代码平台已发布应用下的业务特征，所述业务特征用于表征所述目标API所在的业务场景；确定所述目标API与所述业务特征相匹配的标签。