交互信息处理方法、装置及计算机设备与流程

1.本技术主要涉及计算机技术领域，更具体地说是涉及一种交互信息处理方法、装置及计算机设备。


背景技术：

2.低代码是一种编程量少但能快速设计开发软件应用程序的方法，可以依赖于库、api(application programinterface，应用程序接口)、第三方基础架构，直接在拖放式界面使用可视化建模来组装和配置应用程序，提高应用开发效率和可靠性，降低开发成本，且便于后期维护。
3.其中，在低代码平台设计过程中，通过关键词搜索api，其与前端对应的交互表单绑定，来实现应用交互能力。但在后端的api数量较多的情况下，往往很难快速且准确地搜索到所需api，降低了应用设计开发效率和可靠性。


技术实现要素：

4.有鉴于此，本技术提出了一种交互信息处理方法，所述方法包括：
5.获得针对目标应用的待处理交互表单对应的目标应用程序接口api的api处理请求；
6.响应所述api处理请求，查询已生成的api关系拓扑数据；其中，所述api关系拓扑数据能够表征已发布的不同交互表单各自绑定的api之间的关联关系以及关联因素；
7.依据查询到的所述目标api的查询结果，执行预设操作。
8.可选的，所述api关系拓扑数据的生成方法包括：
9.获取已发布应用所具有的交互表单的相关数据；
10.对所述交互表单的相关数据进行关联性分析，确定各交互表单所绑定的不同api之间的关联关系和关联因素；
11.依据所述不同api之间的关联关系和关联因素，生成api关系拓扑数据。
12.可选的，所述获取已发布应用所具有的交互表单的相关数据，包括：
13.获取已发布应用所具有的交互表单的配置数据，以及访问所述交互表单产生的参数调用数据；
14.所述对所述交互表单的相关数据进行关联性分析，确定各交互表单所绑定的不同api之间的关联关系和关联因素，包括：
15.对所述交互表单的配置数据进行关联性分析，确定各交互表单所绑定的不同api之间的关联关系；
16.对所述参数调用数据进行关联性分析，确定具有所述关联关系的不同api之间的关联因素。
17.可选的，所述获取已发布应用所具有的交互表单的配置数据，以及访问所述交互表单产生的参数调用数据，包括：
18.获取已发布应用所具有的不同交互表单与不同api之间的绑定关系，以及所述不同api各自对应的api参数；所述api参数表征与所对应的api具有绑定关系的所述交互表单中的输出信息；
19.获取在响应对所述已发布应用所具有的任一交互表单访问请求过程中，对该交互表单的api参数调用数据。
20.可选的，所述对所述交互表单的配置数据进行关联性分析，确定各交互表单所绑定的不同api之间的关联关系，包括：
21.依据所述api各自的api参数及所绑定的交互表单、该交互表单所属已发布应用类别，统计任意两个api之间的第一共现概率；
22.依据所述第一共现概率，获得对应的两个api之间具有关联关系的第一置信度；
23.所述第一置信度位于第一置信区间内，则确定对应的两个api之间具有关联关系。
24.可选的，所述对所述参数调用数据进行关联性分析，确定具有所述关联关系的不同api之间的关联因素，包括：
25.利用具有所述关联关系的任意两个api之间的所述api参数调用数据，统计各api参数在不同api调用中的第二共现概率；
26.依据所述第二共现概率，获得所述各api参数使对应的两个api之间具有关联关系的第二置信度；
27.所述第二置信度位于第二置信区间内，则将对应的api参数确定为使对应的两个api之间具有关联关系的关联因素。
28.可选的，所述对所述交互表单的相关数据进行关联性分析，确定各交互表单所绑定的不同api之间的关联关系和关联因素，包括：
29.调取api关联性分析模型；所述api关联性分析模型基于条件概率算法构建；
30.将所述交互表单的相关数据输入所述api关联性分析模型，获得已发布应用所具有的交互表单所绑定的api自身关联的api列表，以及所述api与自身关联的所述api列表中的任一api之间的关联因素。
31.可选的，所述响应所述api处理请求，查询已生成的api关系拓扑数据，包括：
32.获取所述api处理请求携带的待查询信息；所述待查询信息基于所述目标api的目标api参数确定；
33.查询已生成的api关系拓扑数据，获得与所述待查询信息相匹配的多个候选api，以及与所述候选api具有关联关系的关联api和对应的候选关联因素；
34.依据所述关联api的api参数和对应的所述候选关联因素，从所述多个候选api中筛选出所述目标api；
35.所述依据查询到的目标api的查询结果，执行预设操作，包括：
36.对查询到的目标api标识与所述待处理交互表单进行绑定；
37.依据所述待处理交互表单与所述目标api之间的绑定关系，更新所述api关系拓扑数据。
38.本技术还提出了一种交互信息处理装置，所述装置包括：
39.api处理请求获得模块，用于获得针对目标应用的待处理交互表单对应的目标应用程序接口api的api处理请求；
40.目标api查询模块，用于响应所述api处理请求，查询已生成的api关系拓扑数据；其中，所述api关系拓扑数据能够表征已发布的不同交互表单各自绑定的api之间的关联关系以及关联因素；
41.处理模块，用于依据查询到的目标api的查询结果，执行预设操作。
42.本技术还提出了一种计算机设备，所述计算机设备包括：至少一个通信接口、至少一个存储器和至少一个处理器，其中：
43.所述存储器，用于存储如上述的交互信息处理方法的程序；
44.所述处理器，用于加载并执行所述存储器的所述程序，以实现如上述的交互信息处理方法。
45.本技术还提出了一种计算机可读存储介质，其上存储有计算机指令，处理器加载执行该计算机指令，实现如上述的交互信息处理方法。
46.由此可见，本技术提供了一种交互信息处理方法、装置及计算机设备，本技术利用各已发布应用下的各交互表单的相关数据，预先生成能够表征已发布的不同交互表单各自绑定的api之间的关联关系以及关联因素的api关系拓扑数据，这样，在获得针对目标应用的待处理交互表单对应的目标api的api处理请求，响应该api处理请求时，可以直接查询该api关系拓扑数据，综合考虑各api之间的关联关系和关联因素，从而快速且准确地得到目标api的查询结果，执行预设操作，满足业务处理需求。相对于基于api关键词直接从大量api中查询目标api的处理方式，提高了目标api查询效率和准确性。
附图说明
47.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
48.图1为本技术提出的交互信息处理方法的一可选示例的流程示意图；
49.图2为本技术提出的交互信息处理方法的又一可选示例的流程示意图；
50.图3为本技术提出的交互信息处理方法中，生成的api关系拓扑数据的一可选表示方式示意图；
51.图4为本技术提出的交互信息处理方法的又一可选示例的流程示意图；
52.图5为本技术提出的交互信息处理方法的又一可选示例的流程示意图；
53.图6为本技术提出的交互信息处理方法的又一可选示例的流程示意图；
54.图7为本技术提出的交互信息处理装置的一可选示例的结构示意图；
55.图8为本技术提出的交互信息处理装置的又一可选示例的结构示意图；
56.图9为本技术提出的交互信息处理装置的又一可选示例的结构示意图；
57.图10为适用于本技术提出的交互信息处理方法的计算机设备的一可选示例的硬件结构示意图。
具体实施方式
58.目前，应用的开发通常包含前端开发和后端开发，前端开发可以是对应用的前端
页面中交互表单的图片设计，后端开发可以是对支持前端交互表单的业务逻辑实现的代码设计，为了实现后端与前端的对接，后端开发者可以将后端的程序代码暴露为api(application programinterface，应用程序接口)，由前端开发者将设计的交互表单与对应的api进行绑定，以使该交互表单具备交互能力。
59.其中，为了简化开发，可以利用低代码平台中预先开发并封装的大量的组件实现应用开发。对于交互表单的设计，前端开发者可以以一定的逻辑关系或设计布局，通过拖拽该交互表单所需的相关组件，如输入框、编辑框、修改/删除/详情等功能组件完成交互表单的设计，以降低开发者编写代码的工作量，缩短交互表单设计时间，提高开发效率和可靠性。后端开发者也可以在低代码平台上通过拖拽组件的方式，实现交互表单与对应的一个或多个api的绑定，这样，在对交互表单的使用过程中，可以通过调用所触发组件绑定的api，快速实现所需业务，实现过程本技术不做详述。
60.由此可见，为了实现交互表单的交互能力，需要对设计的交互表单绑定所需的一个或多个api(为了方便描述可以记为目标api)，这就需要先从低代码平台上预先开发的大量api组件中，查询该交互表单所需要的目标api，然而，低代码平台上预先开发的api数量往往比较多，若提供的目标api的相关信息不够充分，很难快速且准确地查询到该目标api。
61.为了改善上述问题，提出对低代码平台上的大量api信息进行分类管理，生成预设布局的api目录，这样就可以通过该api目录，来查询定位待处理交互表单所需的目标api，通过缩小api查询范围，来提高查询效率。然而，api目录信息以及api信息的维护需要依赖工作人员个人的认知和经验，这就不可避免出现api目录中api分类不准确或错误的情况，干扰后续对目标api的查询定位。
62.对此，本技术提出基于已发布的不同交互表单各自绑定的api之间的关联关系，以及导致不同api之间的关联关系的关联因素，如对应交互表单中的某一个或多个字段信息等，生成表征该关联关系以及关联因素的api关系拓扑数据，这样，在低代码平台的应用开发场景下，需要确定新设计的交互表单对应的api，或者是在对低代码平台上已开发应用的优化等场景下，需要确定待优化交互表单对应的api等情况下，计算机设备获得对应的api处理请求后，在响应该api处理请求过程中，可以直接查询已生成的该api关系拓扑数据，结合不同api之间的关联关系和关联因素，快速且精准地定位到目标api，执行预设操作。
63.且，由于api关系拓扑数据的生成是通过数据的客观分析，确定出的不同api之间的关联关系和关联因素，无需依赖经验丰富的开发者进行维护，降低了维护成本，保证了api关系拓扑数据的可靠性和准确性，从而提高了目标api查询和定位的准确性，进而降低应用设计开发效率。
64.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
65.参照图1，为本技术提出的交互信息处理方法的一可选示例的流程示意图，该方法可以适用于计算机设备，本技术实际应用中，该计算机设备可以包括终端设备和/或服务设备，其中，终端设备可以包括但并不局限于智能手机、平板电脑、可穿戴设备、增强现实技术(augmented reality，ar)设备、虚拟现实(virtual reality，vr)设备、车载设备、机器人、
智慧医疗设备、智慧交通设备、台式计算机等电子设备；服务设备可以是一台独立的物理服务器，也可以是多台物理服务器构成的服务器集群，还可以是能够实现云计算的云服务器等，服务设备可以通过有线网络或无线网络实现与终端设备的数据通信，满足数据传输需求，关于数据传输的实现方式本技术不做限制，可视情况而定。
66.基于此，以服务设备执行该方法为例进行说明，如图1所示，本实施例提出的交互信息处理方法可以包括但并不局限于以下步骤：
67.步骤s11，获得针对目标应用的待处理交互表单对应的目标api的api处理请求；
68.在本技术实施例中，目标应用可以是低代码平台所开发或正在开发的任一应用，在目标应用开发场景下，对于前端设计的目标应用下的任一交互表单(记为待处理交互表单)，需要绑定至少一个api来实现该交互表单的应用交互能力，这种情况下，前端开发者可以通过客户端登录低代码平台，发起针对该待处理交互表单对应的目标api的api处理请求，以请求查询该目标api是哪一个或多个api。
69.需要说明，对于低代码平台上预先开发的各api来说，其可以与低代码平台所开发的一个应用前端的交互表单进行绑定，也可以与低代码平台所开发的多个应用前端的交互表单进行绑定，还可以与同一应用前端的不同交互表单进行绑定，可视情况而定。对于任一应用前端开发的任一交互表单与所需至少一个api绑定场景下，对该api的查询过程类似，本技术实施例不做一一详述。
70.另外，可以理解，在如应用的交互表单优化等其他场景下，需要查询该交互表单(如待优化等处理的交互表单，统一记为待处理交互表单)将要绑定的优化api时，将该优化api记为目标api，客户端可以生成针对该目标api的api处理请求，将该api处理请求发送至计算机设备，以使计算机设备按照本技术提出的交互信息处理方法，快速且精准地在低代码平台上查询到所需的目标api。
71.可见，客户端生成的api处理请求的请求内容，可以依据对应应用场景的实际应用需求确定，通常可以包括请求处理的目标api的相关信息，以使得计算机设备可以基于请求内容，执行后续精准查询，本技术对api处理请求的生成方式及其包含的请求内容不做限制。
72.步骤s12，响应api处理请求，查询已生成的api关系拓扑数据；
73.继上文对api处理请求的相关描述，计算机设备解析api处理请求，确定客户端所提供的所要查询的待处理交互表单对应的目标api的相关信息，如该目标api信息和/或待处理交互表单信息中的关键词等，之后，依据该相关信息，对已生成的api关系拓扑数据进行查询，由于该api关系拓扑数据能够表征已发布的不同交互表单各自绑定的api之间的关联关系以及关联因素。所以，计算机设备可以依据api处理请求携带的请求内容，对低代码平台上的api关系拓扑数据进行查询，可以得到与该请求内容相匹配的多个api，这样就可以对这多个api之间的关联关系、关联因素进行分析，精准快速定位所请求的目标api，查询过程本技术不做详述。
74.步骤s13，依据查询到的目标api的查询结果，执行预设操作。
75.本技术实施例中，对于上述查询到的目标api的查询结果，可以包括目标api的名称、api参数等信息，由此确定该目标api是哪一个或多个api，之后，可以对该目标api执行预设操作，如将该目标api与待处理交互表单进行绑定，或输出所查询到的目标api信息，以
便开发者对其进行优化更新等，本技术对预设操作的实现方法不做限制，可视情况而定。
76.综上，本技术利用已发布应用的交互表单所绑定的api之间的关联关系、关联因素等api拓扑关系，对各api信息进行补充说明，以使低代码平台上预先开发的各api的画像更清晰，结合api拓扑关系，更容易让api使用者精准识别所需的目标api，据此满足应用需求。相对于基于关键词实现的api查询方式，提高了目标api查询效率和精准度，进而提高了应用开发效率和可靠性，且降低了人工成本。
77.参照图2，为本技术提出的交互信息处理方法的又一可选示例的流程示意图，本实施例可以是对上文实施例描述的交互信息处理方法中，api关系拓扑数据的生成方法的一可选细化实现方式的描述，但并不局限于本实施例描述的这种细化实现方式，关于如何利用该api关系拓扑数据实现目标api查询的其他实现步骤，可以参照上文实施例对应部分的描述，本实施例不做赘述。如图2所示，本实施例提出的api关系拓扑数据的生成方法可以包括：
78.步骤s21，获取已发布应用所具有的交互表单的相关数据；
79.本技术实施例中，已发布应用可以是利用低代码平台开发的任一应用，在应用开发过程中，可以设计该应用所具有的至少一个交互表单，为各交互表单绑定所需的api，对该应用进行测试合格后，发布该应用，以使用户可以使用该应用，即使用该应用所具有的交互表单，满足用户对相应业务使用需求。
80.在上述过程中，可以获得已发布应用的各交互表单绑定api的相关配置数据，以及用户触发交互表单，调用该交互表单所绑定的api时实际使用的api参数，即输出的交互表单所呈现的各字段数据等信息，将其作为该交互表单的相关数据，用于实现对该交互表单的关联性分析。需要说明，关于计算机设备获取的交互表单的相关数据的内容，包括但并不局限于本技术列举的上述信息，可以依据实际需求灵活确定，本技术实施例在此不做一一列举。
81.另外，本技术对已发布应用的应用类型，及其具有的交互表单的相关数据的来源等不做限制，可视情况而定。
82.步骤s22，对交互表单的相关数据进行关联性分析，确定各交互表单所绑定的不同api之间的关联关系和关联因素；
83.数据的关联分析也可以称为关联挖掘，查找不同交互表单的相关数据之间的关联性或相关性，如在不同交互表单中频繁出现的某一种或多种组合数据；若一种数据会与另一种或多种数据同时存在等，由此描述交互表单中某类数据的共性，确定对应的交互表单之间的关联程度等，本技术实现步骤s22的关联性分析所采用的关联分析算法不做限制，可以依据数据类型和特点等，灵活选择适配的关联分析算法实现，实现过程本技术实施例在此不做详述。
84.基于此，由于已发布的同一应用的不同交互表单、不同应用各自的交互表单各自的配置数据，包含有交互表单各自绑定的api，以及每一个交互表单所绑定的多种api参数等信息，按照上述关联性分析方式，对各交互表单的配置数据进行分析，可以确定不同交互表单之间存在的同一种或多种api参数，各api参数在不同交互表单中出现的频率等，之后，可以依据分析得到的这些共性参数，来确定对应的两个交互表单各自绑定的api之间是否存在关联关系；同时还可以交互表单的使用过程中，实际使用的api参数进行关联性分析，
来确定是哪些api参数导致对应交互表单绑定的不同api存在关联关系，即确定导致不同api之间产生关联关系的关联因素。
85.应该理解，对于不同应用中同一类别的交互表单，相同或不同应用下不同交互表单各自绑定的api来说，导致不同api之间产生关联关系的关联因素可能不同，可视情况而定，本技术对各关联因素的内容不作限制。
86.步骤s23，依据不同api之间的关联关系和关联因素，生成api关系拓扑数据。
87.本技术对api关系拓扑数据的表示方式不做限制，可以依据实际需求确定。在一种可能的实现方式中，按照上述分析，确定出存在关联关系的各api，以及导致各api之间的关联关系的关联因素后，可以将这些api作为关系拓扑图的关系节点，将不同关系节点之间的连接线表示对应api之间具有关联关系，且可以在该连接线配置导致该关联关系的关联因素，如图3所示的api关系拓扑数据的一可选表示方式的示意图，如对于低代码平台上开发的api1、api2、api3、api4等，每一个api配置有对应地址id和api参数(图3仅给出两个参数为例进行说明，但并不局限于图3所示的api数量以及各api具有的参数个数)。
88.按照上文描述的关联性分析方式，确定这些api之间的关联关系和关联因素，如api1与api2之间因参数1这一关联因素而产生关联关系，api1与api4之间因参数2这一关联因素而产生关联关系，api2与api3之间因参数4这一关联因素而产生关联关系等，之后，可以据此生成如图3所示关系拓扑结构的api关系拓扑数据，但并不局限于图3所示的关系拓扑结构。
89.可见，通过api关系拓扑结构表示不同api之间的关联关系和关联因素，使得低代码平台上预开发的大量api之间的关联性更加有条理，这样，在需要查询某待处理交互表单所需的目标api的情况下，开发者提供该目标api和/或待处理交互表单的相关信息后，计算机设备可以将其与api关系拓扑数据中，各api具有的api参数进行匹配，结合匹配结果以及不同api之间的关联关系、关系因素，来定位出目标api，实现过程本技术不做详述。
90.参照图4，为本技术提出的交互信息处理方法的又一可选示例的流程示意图，本实施例可以对上文描述的api关系拓扑数据的生成方法的一可选细化实现方式，但并不局限于本实施例描述的这种细化实现方式，如图4所示，该方法可以包括：
91.步骤s41，获取已发布应用所具有的不同交互表单与不同api之间的绑定关系，以及不同api各自对应的api参数；
92.步骤s42，获取在响应对已发布应用所具有的任一交互表单访问请求过程中，对该交互表单的api参数调用数据；
93.结合图5所示的交互信息处理方法的流程示意图，以及上文实施例对本技术技术方案的相关描述，前端开发者完成应用的交互表单的设计搭建后，依据该交互表单的设计内容，为该交互表单绑定所需的至少一个api，如某一列表交互表单中包含修改、删除、详情等组件或事件的情况下，可以将该列表交互表单的列表api与修改api、删除api、详情api进行绑定，结合这些api自身的地址id和api参数等信息，构成该列表交互表单的配置数据。如此完成该应用所设计的各交互表单的api绑定，完成应用开发和测试后，可以将该应用发布至对应应用平台上，关于应用开发测试实现过程本技术不做详述。
94.对于已发布的应用，用户可以下载安装后或在线登录，进入该应用下的任一交互表单，对该交互表单呈现的任一组件进行触发操作时，可以调用与该交互表单绑定的该组
件对应的api参数，实现该组件的业务功能，输出对应的业务数据，此时该业务数据可以是以交互表单方式输出，可以继续访问该交互表单。在该访问过程中可以生成对应的日志数据，包含在交互表单操作过程中对api参数的调用数据等，本技术对该日志数据的内容及其记录方式不做限制。
95.基于此，在需要生成低代码平台上的api关系拓扑数据时，可以获取已发布应用所具有的交互表单的配置数据，以及访问交互表单产生的参数调用数据。如上述分析，该配置数据是在开发应用阶段，设计对应交互表单过程中确定的；参数调用数据可以是指已发布应用运行过程中，对其下的交互表单进行操作所获取的api参数调用数据，本技术对上述配置数据和参数调用数据的，数据内容不做限制，可以依据应用需求确定。
96.步骤s43，依据所获取的api各自的api参数以及该api所绑定的交互表单，该交互表单所属已发布应用类别，统计任意两个api之间的第一共现概率；
97.本技术实际应用中，按照但并不局限于上文描述的方式，对已发布应用下的交互表单的配置数据进行采样后，可以对采样到的交互表单的配置数据进行关联性分析，来确定各交互表单所绑定的不同api之间的关联关系。可选的，对于采集到的大量交互表单配置数据，可以基于配置数据中的api参数进行关联性分析，计算出任意一个api的关联api列表，即与任意一个api具有关联关系的各api，也就是确定出每一个api自身关联的各api，本技术对获取各api的关联api列表所采用的关联分析算法不做限制，对如何实现上述配置数据的关联性分析的实现方法不做限制。
98.在本技术提出的一些实施例中，为了准确地确定低代码平台上的不同api之间是否具有关联关系，本实施例提出采用概率统计方法，如贝叶斯条件概率统计方法等，对获取的不同交互表单的配置数据进行分析，确定任意两个api的共现概率(为了区分，本技术将此处的共现概率记为第一共现概率)，如这两个api同时存在于同一交互表单绑定的多个api中的概率，这两个api同时存在于同一已发布应用的不同交互表单各自绑定的api中的概率，这两个api同时存在于同一类别已发布应用的相同或不同交互表单各自绑定的api中的概率等，本技术对共现概率的统计实现方法不做限制。
99.基于上述分析，为了获取两个api之间的第一共现概率，上文获取的各每一互表单的配置数据中，可以包括不同交互表单与不同api之间的绑定关系、不同api各自对应的api参数、交互表单所属已发布应用类别等信息，且可以理解，在上述数据采样阶段，被采样的已发布应用的数量越多、类别越丰富，被采样的已发布交互表单的数量越多、种类越多，按照本实施例提出这种概率统计方式，所得到的共现概率数值越可靠，使得api关联关系的计算结果越可靠且准确，从而提高后续所得api关系拓扑数据的可靠性和准确性。但本技术对被采样的已发布应用及其下的交互表单各自的数量和类别不做限制，可视情况而定。
100.关于上述共现概率可以是指两个api共同出现的概率，为了提高统计准确性，可以预设合适大小的移动窗口，由此确定一个api的附近(即以该api为中心，向周围辐射到照移动窗口的半径长度所形成的范围)是否出现其他api，若出现了其他api，可以认为这一个api与出现的每一个其他api共现。据此对获取的配置数据进行每两个api共现次数统计，进而计算得到对应两个api的第一共现概率。在该统计过程中，也可以结合api各自所具有的api参数之间的重合度，来确定两个api的第一共现概率，不局限于api信息完全相同的两个api共现统计，实现过程本技术不做详述。
101.需要说明，关于共现概率的计算方法本技术不做限制，根据需要可以采用合适的概率统计算法实现，也可以预先训练得到共现概率统计模型，这样，可以将获取的配置数据直接输入或经预处理后输入共现概率统计模型，输出每两个api的第一共现概率，实现过程本技术不做详述。
102.步骤s44，依据第一共现概率，获得对应的两个api之间具有关联关系的第一置信度；
103.步骤s45，如果该第一置信度位于第一置信区间内，则确定对应的两个api之间具有关联关系；
104.本技术实施例中，若两个api之间的第一共现概率越高，可能是这两个api同时出现在同一已发布应用中，和/或绑定同一交互表单的概率越高等，可以认为这两个api之间的关联程度越高，两者具有关联关系的概率越高，本技术可以采用置信度来表示两个api之间的关联关系成立的可信程度/概率，这种情况下，说明这两个api之间具有关联关系的第一置信度越高，若达到预设的表示两个api之间的关联关系成立的第一置信度区间，可以认为这两个api之间具有关联关系，即这两个api之间的关联关系成立。
105.其中，第一置信区间可以表示两个api之间的关联关系成立的可信程度范围，可以通过对历史数据进行分析确定，本技术对第一置信区间的数值及其确定方法不做限制。
106.结合上述分析，在本技术实施例中，两个api的第一共现概率与两者具有关联关系的第一置信度之间呈正相关，如第一共现概率越大，对应的第一置信度越高，但本技术对第一共现概率与第一置信度之间的转换规则不做限制，即如何依据第一共现概率，确定第一置信度的实现方法不做限制。基于此，对于获得的每两个api的第一共现概率，可以按照预设的第一共现概率与第一置信度之间的转换规则，对第一共现概率进行转换处理，得到对应的第一置信度。
107.之后，调取第一置信区间，将第一置信度与该第一置信区间的上下限数值进行比较，确定第一置信度是否位于第一置信区间内，若是，可以认为对应的两个api之间的关联关系成立；反之，可以认为对应的两个api之间的关联关系不成立，对于不具有关联关系的两个api可以不做进一步关联因素分析。在又一些实施例中，对于预设表示两个api之间的关联关系成立的可信程度，也可以确定为第一置信阈值(如85％等，本技术对其数值不做限制)，检测所获得的第一置信度(如90％等)达到第一置信阈值，可以认为这两个api之间具有关联关系，本技术对如何检测两个api之间的关联关系是否成立的实现方法不做限制。
108.按照本技术上文描述的关联性分析实现方法，对于低代码平台上预开发的每一个api，通常可以确定与其具有关联关系的至少一个其他api，记为关联api列表。需要说明，同一交互表单绑定的多个api之间可能具有关联关系，如列表api绑定的删除api、修改api、详情api等可能具有关联关系，这些绑定的api之间也可能存在不具有关联关系的api，可以按照上文描述方式进行关联性分析确定。同理，对于同一应用下的不同交互表单各自绑定的同一类api之间，以及不同应用下的相同或不同交互表单绑定的同一类api之间，由于api参数等信息可能存在差异，导致同一类api之间可能具有关联关系，也可能不具有关联关系，这可视情况而定。
109.步骤s46，利用具有关联关系的任意两个api之间的api参数调用数据，统计各api参数在不同api调用中的第二共现概率；
110.本技术按照上文描述的方法，确定两个api之间具有关联关系后，可以进一步确定导致这两个api具有关联关系的关联因素是什么，如因什么api参数使得这两个api绑定同一交互表单、绑定同一应用的不同交互表单等。对此，本技术提出在运行低代码已发布应用过程中，记录访问各交互表单对api及其api参数的调用数据，在上述数据采样阶段，可以采集api参数调用数据，利用关联分析算法，对具有关联关系的api的参数调用数据进行分析，以确定对应的关联因素。
111.在一些实施例中，可以基于共现概率统计和置信度分析，来确定具有关联关系的api之间的参数对应关系，即确定关联api的关联因素。所以，本技术可以对获得的大量具有关联关系的api的api参数调用数据进行共现概率统计，确定各api参数在不同api调用中的第二共现概率。通常情况下，某api参数在不同api调用中的第二共现概率越高，说明该api参数是使得对应的两个api具有关联关系的关联因素的概率越高，本技术对第二共现概率的统计实现方法不做详述，可以结合共现概率统计的运算原理确定。
112.需要说明，对于部分已确定的具有关联关系的api之间，可能会存在无api参数对应关系的情况下，这往往属于这两个api是通过应用场景建立的关联关系。所以，在上述每两个api之间的关联关系的分析过程，不仅可以依据api参数确定，还可以结合api应用场景确定，如适用于同一应用场景下的不同api可以存在关联关系，这可以依据预先配置的至少一个关联关系分析条件确定。
113.步骤s47，依据该第二共现概率，获得各api参数使对应的两个api之间具有关联关系的第二置信度；
114.步骤s48，如果该第二置信度位于第二置信区间内，则将对应的api参数确定为使对应的两个api之间具有关联关系的关联因素；
115.结合上文实施例对第一共现概率与第一置信度的第一转换规则的相关描述，本技术也可以预先确定第二共现概率和第二置信度之间的第二转换规则，该第二转换规则与第一转换规则可以相同，也可以不同，这可以依据实际分析结果确定，本技术对各转换规则的内容不做详述。本技术按照第二转换规则，利用获得的第二共现概率，转换得到该api参数是对应两个关联api的关联因素的第二置信度，也就是说该api参数影响这两个api具有关联关系的第二置信度。
116.其中，可以理解，同一api参数对不同组api的关联关系的影响方向可能不同，可能会增大该组的两个api之间的关联关系成立的概率；也可能会增大该组的两个api之间的关联关系不成立的概率，所以说，同一api参数对不同组api的关联关系的第二置信度可能不同。
117.由于第二置信度表示对应的api参数使得两个api之间的关联关系成立的可信程度，且第二置信度越高，可以认为该api参数在确定两个api之间具有关联关系中起到的正向影响力越大。所以，在预设api参数成为两个api之间具有关联关系的关联因素的第二置信区间，即api参数的置信度达到多少可信范围，认为该api参数是影响两个api具有关联关系的关联因素，可以将获得第二置信度与第二置信区间进行比较，若第二置信度位于第二置信区间内，确定对应的api参数是使得对应两个api之间的关联关系成立的关联因素，如图3所示，api1和api2之间的关联因素包括参数1，api2和api3之间的关联因素包括参数4；反之，可以认为对应的api参数是对应两个api之间的区别因素。
118.其中，在上述关联因素的分析过程中，可以结合api参数在关联的两个api中的第二共现概率，以及api参数与api应用场景之间的关联度等信息，来确定该api参数使得对应两个api关联的第二置信度，本技术对上述各置信度的获取方法不做限制。
119.需要说明，对于上述关联关系可以包括直接关联关系，如图3所示的api1和api2之间的关联关系、api2和api3之间的关联关系、api1和api4之间的关联关系；还可以包括间接关联关系，如ap1和api3之间的关联关系，此时两者之间的关联因素可以包括ap1的参数1和api2的参数4，但并不局限于图3所示的关联关系。
120.步骤s49，依据不同api之间的关联关系和关联因素，生成api关系拓扑数据。
121.如图5所示，对于生成的api关系拓扑数据，可以发送至数据库进行存储，以供后续客户端查询目标api时调取，本技术对api关系拓扑数据的存储实现方法不做限制，可视情况而定。
122.综上，本技术实施例通过获取大量已发布应用下的各交互表单的配置数据，经过关联性分析，确定每一api的关联api列表，即确定每两个api之间的关联关系是否成立；再通过获取已发布应用运行过程中，对其中的交互表单进行操作所产生的api参数调用数据，经过关联性分析后，进一步确定具有关联关系的两个api之间的关联因素，之后，可以结合低代码平台上预开发的任两个api之间的关联关系和关联因素，生成api关系拓扑实现对api信息的补充，通过api关系拓扑数据，更加清晰有条理地记录低代码平台上预开发的大量api，即更加准确且全面地对各api进行画像，有助于快速且精准地从大量api中查询定位出所需的目标api。
123.其中，对于上述关联性分析算法，本技术提出基于共现概率统计和置信度分析方式，来确定不同api之间的关联关系是否成立，以及关联关系成立的两个api之间的关联因素是什么，由此快速且准确地生成低代码平台上预开发的大量api之间的关系拓扑结构。当然，本技术也可以采用其他关联性分析算法，实现api关联关系和关联因素的分析，本技术在此不做详述。
124.在本技术提出的又一些实施例中，本技术也可以预先构建api关联性分析模型，如基于条件概率算法(如贝叶斯条件概率等)，对采集到的样本数据进行分析，构建api关联性分析模型，用于实现任意两个api之间的关联关系是否成立，以及关联关系成立的api之间的关联因素。所以，本技术按照上文方法完成数据采样后，可以调取预先构建的api关联性分析模型，将获取的交互表单的相关数据(如上述各交互表单的配置数据、api参数调用数据等)输入该api关联性分析模型，获得已发布应用所具有的交互表单所绑定的api自身关联的api列表，以及该api与自身关联的api列表中的任一api之间的关联因素，实现过程本技术不做详述。
125.参照图6，为本技术提出的交互信息处理方法的又一可选示例的流程示意图，本实施例可以是上文描述的交互信息处理方法的又一可选细化实现方法，结合上文实施例描述的api关系拓扑数据生成方法，利用预先生成的api关系拓扑数据，快速且精准地从大量api中查询出所需的目标api，满足后续对目标api的处理需求。如图6所示，本实施例提出的交互信息处理方法可以包括但并不局限于如下步骤：
126.步骤s61，获得针对目标应用的待处理交互表单对应的目标api的api处理请求；
127.步骤s62，获取该api处理请求携带的待查询信息；
128.结合上文实施例对api处理请求的相关描述，计算机设备通过解析该api处理请求，获得其包含的请求内容，记为待查询信息。其中，如上述分析，待查询信息可以是基于目标api的目标api参数确定，根据需要也可以结合待处理交互表单的表单数据确定待查询信息。在实际应用中，待查询信息可以包括但并不局限于目标api的关键词，也可以包括用于描述目标api的描述信息等，可视情况而定，本技术不做详述。
129.步骤s63，查询已生成的api关系拓扑数据，获得与待查询信息相匹配的多个候选api，以及与候选api具有关联关系的关联api和对应的候选关联因素；
130.结合上文对api关系拓扑数据的相关描述，本技术确定目标api的待查询信息，即用于确定哪一个或多个api为目标api的信息后，可以利用该待查询信息对api关系拓扑数据进行查询，如将待查询信息与api关系拓扑数据包含的各api的api信息(如api参数等，该api信息可以是api基础信息，可以通过自身的api标识在api信息模型数据中查询，并不要求记录在api关系拓扑数据中，也就是说，api关系拓扑数据可以记录api标识，用以获取对应api具有的api信息，实现过程本技术不做详述)进行匹配，从大量api中粗略选择出可能是目标api的多个候选api。其中，候选api是指api信息与待查询信息的匹配度达到匹配阈值(本技术对其数值不做限制，可视情况而定)的api，可以通过但并不局限于相似度算法实现，实现过程本技术不做详述。
131.之后，对于查询到的每个候选api，可以通过api关系拓扑数据记录的api关系拓扑，确定该候选api的关联api列表，以及各关联api所具有的api参数，和该候选api与每个关联api的关联因素，本实施例将此处查询到的候选api及其关联api之间的关联因素记为候选关联因素。
132.其中，对于api关系拓扑数据中的各api，可以配置对应的api标识，用以区分不同的api；对于不同身份的api，可以配置对应的表示该身份的身份标识，如apix的关联api列表中的各关联api，可以配置表示与apix关联的关联标识，记为关联api标识。可以理解，对于同一api来说，其可以具有自身的api标识，且在其与多个其他api关联的情况下，可以为其配置对应的与每一个其他api关联所对应的关联api标识，使得该api具有对应的多个关联api标识，但并不局限于这种记录方式。
133.基于此，在上述查询候选api的关联api列表的过程中，可以依据该候选api具有的api标识，搜索其关联api列表，如可以搜索具有概候选api对应的关联api标识的关联api等，此时搜索到的关联api列表包含的各关联api可以由各自对应的api标识表示，但并不局限于这种查询结果表示方式，且本技术对上述各api标识、关联api标识的内容不做限制，可以是数字、字母、字符等。
134.步骤s64，依据关联api的api参数和对应的候选关联因素，从多个候选api中筛选出目标api；
135.对于查询到的每个候选api，本技术可以进一步对其关联api及其包含的api参数、关联因素进行分析，来确定该候选api是否为所需的目标api，相对于直接通过待查询信息进行匹配，确定目标api的查询方式，极大提高了目标api的查询准确性。
136.在一些实施例中，计算机设备可以将每一个候选api的关联api及其包含的api参数、关联因素等信息，再次与待查询信息进行匹配分析，还可以结合待处理交互表单的表单数据，甚至是多个候选api各自的这些信息之间的比较，综合确定出目标api。
137.在又一些实施例中，本技术也可以将查询出的多个候选api，以关系拓扑图的方式输出，前端开发者从中选定某一候选api，可以在当前信息输出界面呈现所选择的候选api的关联api列表，甚至可以呈现各关联api对应的关联因素，或者是进一步从关联api列表中选择某一关联api，查看该候选api与该关联api之间的关联因素，本技术对上述查询结果的输出方式不作限制，可视情况而定。对于该又一些实施例描述的输出方式，可以辅助前端开发者从多个候选api中，快速且准确地确定出所需的目标api，选择实现过程本技术不做详述。
138.可见，本技术通过api关系拓扑数据，可以快速且精准查询到待处理交互表单的目标api，以及该目标api的关联api列表，即与目标api具有关联关系的各关联api，各关联api的api信息、关联因素等，以供开发者查看目标api的相关信息，可以据此实现应用/待处理交互表单的优化等。
139.步骤s65，对查询到的目标api标识与待处理交互表单进行绑定；
140.步骤s66，依据待处理交互表单与目标api之间的绑定关系，更新api关系拓扑数据。
141.在本技术实施例中，利用预先生成的api关系拓扑数据，快速且精准地查询出待处理交互表单对应的目标api后，可以依据当前业务需求，依据该目标api执行预设操作，如图5所示，在开发应用场景下，对于新设计的交互表单，可以按照上文描述的方法查询其需要绑定的各目标api，即在低代码开发过程中，通过api关系拓扑数据快速且精准地查询/定位目标api，之后，可以将该目标api的目标api标识与该交互表单进行绑定，完成应用开发设计，提高应用开发效率和可靠性。
142.对于新生成的交互表单与目标api的绑定关系后，其可能会影响已有api关系拓扑数据中，各api之间的关联关系；对开发应用的交互表单的使用，也可能会影响已有关联的api之间的关联因素，所以，本技术可以依据新构建的绑定关系、目标api的api信息、新设计的交互表单，甚至是对交互表单使用产生的api参数调用数据，按照上文描述的方法，重新生成api关系拓扑数据。
143.为了减少工作量，本技术也可以分析这些数据对当前存在的api关系拓扑数据中的关联关系、关联因素的影响力是否达到阈值，若达到，说明这些数据会使得已存在的api之间的关联关系、关联因素发生变化，可以结合这些数据更新关联关系和关联因素，如增加新的关联关系和/或关联因素，修改已有关联关系和/或关联因素等，本技术对该更新实现方法不做限制，可视情况而定；若未达到，说明这些数据不会导致已存在的api之间的关联关系、关联因素的改变，无需更新api关系拓扑数据。
144.需要说明，关于本技术获得的目标api的查询结果后，所执行的预设操作，包括当并不局限于本实施例描述的绑定操作；如在api优化场景下，也可以输出目标api的查询结果，以供后端开发者据此实现api信息优化，再将优化后得到的api信息更新至api关系拓扑数据中，或按照上文描述的方法，重新确定api关系拓扑等，实现过程本技术不做详述。
145.参照图7，为本技术提出的交互信息处理装置的一可选示例的结构示意图，该装置可以包括：
146.api处理请求获得模块71，用于获得针对目标应用的待处理交互表单对应的目标应用程序接口api的api处理请求；
147.目标api查询模块72，用于响应所述api处理请求，查询已生成的api关系拓扑数据；其中，所述api关系拓扑数据能够表征已发布的不同交互表单各自绑定的api之间的关联关系以及关联因素；
148.处理模块73，用于依据查询到的目标api的查询结果，执行预设操作。
149.在一些实施例中，为了生成上述api关系拓扑数据，如图8所示，本技术提出的交互信息处理装置还可以包括：
150.数据获取模块74，用于获取已发布应用所具有的交互表单的相关数据；
151.关联分析模块75，用于对所述交互表单的相关数据进行关联性分析，确定各交互表单所绑定的不同api之间的关联关系和关联因素；
152.关系拓扑生成模块76，用于依据所述不同api之间的关联关系和关联因素，生成api关系拓扑数据。
153.在一些实施例中，上述数据获取模块74可以包括：
154.配置数据获取单元，用于获取已发布应用所具有的交互表单的配置数据；
155.参数调用数据获取单元，用于获取访问已发布应用下的交互表单产生的参数调用数据；
156.对此，上述关联分析模块75可以包括：
157.第一关联分析单元，用于对所述交互表单的配置数据进行关联性分析，确定各交互表单所绑定的不同api之间的关联关系；
158.第二关联分析单元，用于对所述参数调用数据进行关联性分析，确定具有所述关联关系的不同api之间的关联因素。
159.基于上述分析，在又一些实施例中，上述数据获取模块74可以包括：
160.第一获取单元，用于获取已发布应用所具有的不同交互表单与不同api之间的绑定关系，以及所述不同api各自对应的api参数；所述api参数表征与所对应的api具有绑定关系的所述交互表单中的输出信息；
161.第二获取单元，用于获取在响应对所述已发布应用所具有的任一交互表单访问请求过程中，对该交互表单的api参数调用数据。
162.基于此，上述第一关联分析单元可以包括：
163.第一共现概率统计单元，用于依据所述api各自的api参数及所绑定的交互表单、该交互表单所属已发布应用类别，统计任意两个api之间的第一共现概率；
164.第一置信度获得单元，用于依据所述第一共现概率，获得对应的两个api之间具有关联关系的第一置信度；
165.关联关系确定单元，用于在第一置信度位于第一置信区间内的情况下，确定对应的两个api之间具有关联关系。
166.可选的，上述第二关联分析单元可以包括：
167.第二共现概率统计单元，用于利用具有所述关联关系的任意两个api之间的所述api参数调用数据，统计各api参数在不同api调用中的第二共现概率；
168.第二置信度获得单元，用于依据所述第二共现概率，获得所述各api参数使对应的两个api之间具有关联关系的第二置信度；
169.关联因素确定单元，用于在第二置信度位于第二置信区间内的情况下，将对应的
api参数确定为使对应的两个api之间具有关联关系的关联因素。
170.在本技术提出的又一些实施例中，上述关联分析模块75还可以包括：
171.模型调取单元，用于调取api关联性分析模型；所述api关联性分析模型基于条件概率算法构建；
172.模型分析单元，用于将所述交互表单的相关数据输入所述api关联性分析模型，获得已发布应用所具有的交互表单所绑定的api自身关联的api列表，以及所述api与自身关联的所述api列表中的任一api之间的关联因素。
173.基于上文各实施例描述的交互信息处理装置，如图9所示，上述各实施例中的目标api查询模块72可以包括：
174.待查询信息获取单元721，用于获取所述api处理请求携带的待查询信息；所述待查询信息基于所述目标api的目标api参数确定；
175.候选信息获得单元722，用于查询已生成的api关系拓扑数据，获得与所述待查询信息相匹配的多个候选api，以及与所述候选api具有关联关系的关联api和对应的候选关联因素；
176.目标api筛选单元723，用于依据所述关联api的api参数和对应的所述候选关联因素，从所述多个候选api中筛选出所述目标api；
177.对此，在一些实施例中，如图9所示，上述处理模块73可以包括：
178.绑定单元731，用于对查询到的目标api标识与所述待处理交互表单进行绑定；
179.更新单元732，用于依据所述待处理交互表单与所述目标api之间的绑定关系，更新所述api关系拓扑数据。
180.需要说明的是，关于上述各装置实施例中的各种模块、单元等，均可以作为程序模块存储在存储器中，由处理器执行存储在存储器中的上述程序模块，以实现相应的功能，关于各程序模块及其组合所实现的功能，以及达到的技术效果，可以参照上述方法实施例相应部分的描述，本实施例不再赘述。
181.本技术还提供了一种计算机可读存储介质，其上可以存储计算机程序，该计算机程序可以被处理器调用并加载，以实现上述实施例描述的交互信息处理方法的各个步骤，实现过程可以参照上文实施例相应部分的描述，本实施例在此不做详述。
182.参照图10，为适用于本技术提出的交互信息处理方法的计算机设备的一可选示例的硬件结构示意图，如上述分析，该计算机设备可以是终端设备或服务设备，以服务设备为例进行说明，如图10所示，其硬件结构组成可以包括但并不局限于：至少一个通信接口101、至少一个存储器102和至少一个处理器103，其中：
183.通信接口101可以是通信模块的数据接口，支持计算机设备与外部其他设备、内部组成部件之间的数据通信，本技术对该通信接口101的类别及数量不做限制，可视情况而定。其中，通信模块可以包括能够利用无线通信网络实现数据交互的通信模块，如wifi模块、5g/6g(第五代移动通信网络/第六代移动通信网络)模块、gprs模块、近场通信模块、gms模块等，对于不同通信模块的通信接口类型及其支持的通信协议等可能不同，可以依据该通信模块的通信要求确定，本技术不做一一详述。
184.其中，为了实现计算机设备内部组件的通信，上述通信接口101还可以包括usb接口、串/并口、多媒体数据接口等，可以依据计算机设备的产品类型及其配置要求确定，本申
请不做一一列举。
185.存储器102可以用于存储实现上述各方法实施例描述的交互信息处理方法的程序；处理器1103可以加载并执行存储器102存储的该程序，以实现上述相应方法实施例描述的交互信息处理方法的各个步骤，具体实现过程可以参照上述实施例相应部分的描述，本实施例在此不再赘述。
186.在实际应用中，通信接口101、存储器102和处理器103可以连接通信总线，通过该通信总线实现相互之间，以及与计算机设备的其他结构组成之间的数据交互，具体可以根据实际需求确定，本技术不做详述。
187.本技术实施例中，存储器102可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。处理器103，可以为中央处理器(centralprocessing unit，cpu)、特定应用集成电路(application-specific integrated circuit，asic)、数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件等。本技术对上述存储器102和处理器103的结构及其型号不做限定，可以根据实际需求灵活调整。
188.应该理解的是，图10所示的计算机设备的结构并不构成对本技术实施例中计算机设备的限定，在实际应用中，计算机设备可以包括比图10所示的更多的部件，或者组合某些部件。如在计算机设备为终端设备的情况下，该计算机设备还可以包括如感应触摸显示面板上的触摸事件的触摸感应单元、键盘、鼠标、摄像头、拾音器等至少一个输入组件；如显示器、扬声器、振动机构、灯等至少一个输出组件；天线；传感器模组；电源模组等，可以依据终端设备类型及其功能需求确定硬件结构；在计算机设备为服务设备的情况下，该计算机设备还可以包括监控设备、数据库等，本技术在此不做一一列举。
189.最后，需要说明的是，关于上述各实施例中，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
190.其中，在本技术实施例的描述中，除非另有说明，“/”表示或的意思，例如，a/b可以表示a或b；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，在本技术实施例的描述中，“多个”是指两个或多于两个。
191.本技术涉及到的术语诸如“第一”、“第二”等仅用于描述目的，用来将一个操作、单元或模块与另一个操作、单元或模块区分开来，而不一定要求或者暗示这些单元、操作或模块之间存在任何这种实际的关系或者顺序。且不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量，由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。
192.另外，本说明书中各个实施例采用递进或并列的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、计算机设备而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。
193.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。