API推荐方法及API推荐装置.pdf

本申请实施例公开了一种应用开发接口API推荐方法及推荐装置，所述方法包括：获取多个权限的安全风险聚类信息；确定所述多个权限中一应用程序已使用的一权限；根据所述安全风险聚类信息和所述已使用的权限确定所述多个权限中与所述已使用的权限相关的至少一权限；根据所述至少一权限确定至少一API。本申请实施例的至少一个实施方案使得集成开发环境可以基于安全风险和功能因素给开发者提供可供选择的API，进而使得开发者可以快速准确的选择具有合适的安全风险和功能的API。

1.  一种应用开发接口API推荐方法，其特征在于，包括：
获取多个权限的安全风险聚类信息；
确定所述多个权限中一应用程序已使用的一权限；
根据所述安全风险聚类信息和所述已使用的权限确定所述多个权限中与所述已使用的权限相关的至少一权限；
根据所述至少一权限确定至少一API。

2.  如权利要求1所述的方法，其特征在于，所述根据所述至少一权限确定所述至少一API包括：
确定与所述至少一权限相关的至少一应用程序；
获取所述至少一应用程序使用的至少一候选API；
根据设定的至少一确定标准在所述至少一候选API中确定所述至少一API。

3.  如权利要求2所述的方法，其特征在于，所述确定与所述至少一权限相关的所述至少一应用程序包括：
所述至少一应用程序中的每个应用程序申请所述至少一权限中的至少一权限。

4.  如权利要求3所述的方法，其特征在于，所述根据设定的至少一确定标准在所述至少一候选API中确定所述至少一API包括：
获取所述至少一应用程序中的每个应用程序与所述至少一候选API中每个API之间的API使用权值；
获取所述至少一应用程序中的每个应用程序申请所述至少一权限中每个权限的申请关系的权值；
根据所述API使用权值和所述申请关系的所述权值得到所述至少一候选API中每个API的推荐值；
根据所述推荐值确定所述至少一API。

5.  如权利要求1所述的方法，其特征在于，根据所述安全风险 聚类信息和所述已使用的权限确定所述至少一权限包括：
根据所述安全风险聚类信息确定所述已使用的权限所属的一安全风险聚类分组；
根据所述安全风险分组确定所述至少一权限。

6.  如权利要求1所述的方法，其特征在于，获取所述多个权限的安全风险聚类信息包括：
确定多个应用程序与所述多个权限之间的多个申请关系；其中，所述多个申请关系中的每个申请关系对应于所述多个应用程序中的一应用程序申请所述多个权限中的一权限；
确定所述多个申请关系中每个申请关系的权值；
根据所述每个申请关系的所述权值对所述多个权限进行安全风险聚类，得到所述安全风险聚类信息。

7.  如权利要求6所述的方法，其特征在于，确定所述权值包括：
根据所述每个申请关系对应的所述应用程序申请所述权限的概率确定所述每个申请关系的权值。

8.  如权利要求6所述的方法，其特征在于，确定所述权值包括：
根据所述每个申请关系对应的所述应用程序所属的一应用分类中所述所有应用程序申请所述权限的频率与所述所有应用程序分别申请所述多个权限的多个频率之和的比值得到所述权值。

9.  如权利要求6所述的方法，其特征在于，根据所述权值对所述多个权限进行安全风险聚类包括：
获取与所述多个权限一一对应的多个权值向量；
根据所述多个权值向量对所述多个应用程序进行安全风险聚类；
其中，所述多个权值向量中的每个权值向量中包含与所述多个应用程序一一对应的多个元素，其中，对于每个权值向量：
对应于与所述权值向量对应的权限与所述多个应用程序中的一应用程序之间有申请关系，所述权值向量中与所述应用程序对应的元 素为所述申请关系的权值；
对应于与所述权值向量对应的权值与所述多个应用程序中的一应用程序之间没有申请关系，所述权值向量中与所述应用程序对应的元素为0。

10.  如权利要求9所述的方法，其特征在于，所述根据所述多个权值向量对所述多个权限进行安全风险聚类包括：
根据所述多个权限中两个权限分别对应的权值向量的相似度来对所述多个权限进行安全风险聚类。

11.  如权利要求9所述的方法，其特征在于，所述根据所述多个权值向量对所述多个权限进行安全风险聚类包括：
通过基于距离的聚类算法对所述多个权值向量进行聚类，进而确定所述多个权限的安全风险聚类。

12.  如权利要求6所述的方法，其特征在于，所述方法还包括：存储所述安全风险聚类信息。

13.  一种应用开发接口API推荐装置，其特征在于，包括：
聚类信息获取模块，用于获取多个权限的安全风险聚类信息；
已使用权限确定模块，用于确定所述多个权限中一应用程序已使用的一权限；
相关权限确定模块，用于根据所述安全风险聚类信息和所述已使用的权限确定所述多个权限中与所述已使用的权限相关的至少一权限；
API确定模块，用于根据所述至少一权限确定至少一API。

14.  如权利要求13所述的装置，其特征在于，所述API确定模块包括：
应用程序确定子模块，用于确定与所述至少一权限相关的至少一应用程序；
候选API确定子模块，用于获取所述至少一应用程序使用的至少 一候选API；
API确定子模块，用于根据设定的至少一确定标准在所述至少一候选API中确定所述至少一API。

15.  如权利要求14所述的装置，其特征在于，所述应用程序确定子模块确定的所述至少一应用中的每个应用程序申请所述至少一权限中的至少一权限。

16.  如权利要求15所述的装置，其特征在于，所述候选API确定子模块包括：
API使用权值获取单元，用于获取所述至少一应用程序中的每个应用程序与所述至少一候选API中每个API之间的API使用权值；
申请关系权值获取单元，用于获取所述至少一应用程序中的每个应用程序申请所述至少一权限中每个权限的申请关系的权值；
推荐值获取单元，用于根据所述API使用权值和所述申请关系的所述权值得到所述至少一候选API中每个API的推荐值；
API确定单元，用于根据所述推荐值确定所述至少一API。

17.  如权利要求13所述的装置，其特征在于，所述相关权限确定模块包括：
安全风险分组确定子模块，用于根据所述安全风险聚类信息确定所述已使用的权限所属的一安全风险分组；
相关权限确定子模块，用于根据所述安全风险分组确定所述至少一权限。

18.  如权利要求13所述的装置，其特征在于，所述聚类信息获取模块包括：
申请关系确定子模块，用于确定多个应用程序与所述多个权限之间的多个申请关系；其中，所述多个申请关系中的每个申请关系对应于所述多个应用程序中的一应用程序申请所述多个权限中的一权限；
权值确定子模块，用于确定所述多个申请关系中每个申请关系的 权值；
聚类信息获取子模块，用于根据所述每个申请关系的所述权值对所述多个权限进行安全风险聚类，得到所述安全风险聚类信息。

19.  如权利要求18所述的装置，其特征在于，所述权值确定子模块包括：
第一权值确定单元，用于根据所述每个申请关系对应的所述应用程序申请所述权限的概率确定所述每个申请关系的权值。

20.  如权利要求18所述的装置，其特征在于，所述权值确定子模块包括：
第二权值确定单元，用于根据所述每个申请关系对应的所述应用程序所属的一应用分类中所述所有应用程序申请所述权限的频率与所述所有应用程序分别申请所述多个权限的多个频率之和的比值得到所述权值。

21.  如权利要求18所述的装置，其特征在于，所述聚类信息获取子模块包括：
权值向量获取单元，用于获取与所述多个权限一一对应的多个权值向量；
权限聚类单元，用于根据所述多个权值向量对所述多个应用程序进行安全风险聚类；
其中，所述多个权值向量中的每个权值向量中包含与所述多个应用程序一一对应的多个元素，其中，对于每个权值向量：
对应于与所述权值向量对应的权限与所述多个应用程序中的一应用程序之间有申请关系，所述权值向量中与所述应用程序对应的元素为所述申请关系的权值；
对应于与所述权值向量对应的权值与所述多个应用程序中的一应用程序之间没有申请关系，所述权值向量中与所述应用程序对应的元素为0。

22.  如权利要求21所述的装置，其特征在于，所述权限聚类单元包括：
第一聚类子单元，用于根据所述多个权限中两个权限分别对应的权值向量的相似度来对所述多个权限进行安全风险聚类。

23.  如权利要求21所述的装置，其特征在于，所述权限聚类单元包括：
第二聚类子单元，用于通过基于距离的聚类算法对所述多个权值向量进行聚类，进而确定所述多个权限的安全风险聚类。

24.  如权利要求18所述的装置，其特征在于，所述装置还包括：
存储模块，用于存储所述安全风险聚类信息。

25.  一种电子设备，其特征在于，包括权利要求13-24中任一项所述的应用开发接口API推荐装置。

API推荐方法及API推荐装置
技术领域
本申请涉及一种数据处理方法，尤其涉及一种API推荐方法及API推荐装置。
背景技术
近年来随着移动设备与移动互联网的高速发展，移动应用程序的数量出现了爆炸式的增长。与此同时，移动应用程序的功能被极大的扩展，用以丰富和满足用户各种各样的需求，例如：基于位置的服务(Location Based Services，LBS)，基于社交平台的服务(Social Networking Services，SNS)，等等。事实上，这些丰富的功能依赖于各种用户数据和设备的使用权限，例如位置访问权、通讯录访问权、短信访问权等等。这些访问权限的使用，使得用户产生了对于自身隐私、安全的担心。
丰富的API往往给应用程序的开发者带来困惑——不知道为了实现一个功能应该使用哪些应用开发接口(Application Programming Interface，API)以达到更好的效果。为了降低门槛，也为了开发者更高效的工作，集成开发环境提供者常常会在相应的开发环境中提供基于前缀匹配的API提示/推荐等功能。
发明内容
本申请的目的是：提供一种基于安全风险的API推荐技术。
第一方面，本申请一个实施方案提供了一种API推荐方法，包括：
获取多个权限的安全风险聚类信息；
确定所述多个权限中一应用程序已使用的一权限；
根据所述安全风险聚类信息和所述已使用的权限确定所述多个权限中与所述已使用的权限相关的至少一权限；
根据所述至少一权限确定至少一API。
第二方面，本申请一个实施方案提供了一种API推荐装置，包括：
聚类信息获取模块，用于获取多个权限的安全风险聚类信息；
已使用权限确定模块，用于确定所述多个权限中一应用程序已使用的一权限；
相关权限确定模块，用于根据所述安全风险聚类信息和所述已使用的权限确定所述多个权限中与所述已使用的权限相关的至少一权限；
API确定模块，用于根据所述至少一权限确定至少一API。
第三方面，本申请一个实施方案提供了一种电子设备，包括上面所述的API推荐装置。
本申请实施例的至少一个实施方案通过一应用程序中已使用的权限来找到与该权限安全风险相似的权限，并根据这些安全风险相似的权限来得到相关的应用程序所使用的API，进而对应用程序的开发者进行基于安全风险的API推荐。使得集成开发环境可以基于安全风险和功能因素给开发者提供可供选择的API，进而使得开发者可以快速准确的选择具有合适的安全风险和功能的API。
附图说明
图1为本申请实施例的一种API推荐方法的流程图；
图2为本申请实施例的一种API推荐方法获取安全风险聚类信息的流程图；
图3a为本申请实施例的一种API推荐方法中应用程序与权限的二部图示意图；
图3b为本申请实施例一种API推荐方法的应用场景示意图；
图4为本申请实施例一种API推荐装置的结构示意框图；
图5a为本申请实施例一种API推荐装置的聚类信息获取模块的结构示意框图；
图5b为本申请实施例一种API推荐装置的聚类信息获取模块的结构示意框图；
图5c为本申请实施例一种API推荐装置的权值确定子模块的结构示意框图；
图5d和5e分别为本申请实施例两种API推荐装置的权限聚类单元的结构示意框图；
图6a为本申请实施例又一种API推荐装置的结构示意框图；
图6b为本申请实施例一种API推荐装置的已使用权限确定模块的结构示意框图；
图6c为本申请实施例一种API推荐装置的API确定模块的结构示意框图；
图6d为本申请实施例一种API推荐装置的API确定子模块的结构示意框图；
图7为本申请实施例一种电子设备的结构示意框图；
图8为本申请实施例再一种API推荐装置的结构示意框图。
具体实施方式
下面结合附图(若干附图中相同的标号表示相同的元素)和实施例，对本申请的具体实施方式作进一步详细说明。以下实施例用于说明本申请，但不用来限制本申请的范围。
本领域技术人员可以理解，本申请中的“第一”、“第二”等术语仅用于区别不同步骤、设备或模块等，既不代表任何特定技术含义，也不表示它们之间的必然逻辑顺序。
本申请发明人发现应用程序开发者在开发过程中选择API时还要考虑到用户对安全风险方面的需求，因此，如图1所示，本申请实施例提供了一种API推荐方法，包括：
S110获取多个权限的安全风险聚类信息；
S120确定所述多个权限中一应用程序已使用的一权限；
S130根据所述安全风险聚类信息和所述已使用的权限确定所述多个权限中与所述已使用的权限相关的至少一权限；
S140根据所述至少一权限确定至少一API。
举例来说，本发明提供的API推荐装置作为本实施例的执行主体，执行S110～S140。具体地，所述API推荐装置可以以软件、硬件或软硬件结合的方式设置在用户设备或服务器设备中。
本申请实施例的至少一个实施方案通过一应用程序中已使用的权限来找到与该权限安全风险相似的权限，并根据这些安全风险相似的权限来得到相关的应用程序所使用的API，进而对应用程序的开发者进行基于安全风险的API推荐。使得集成开发环境可以基于安全风险和功能因素给开发者提供可供选择的API，进而使得开发者可以快速准确的选择具有合适的安全风险和功能的API。
通过下面的实施方式进一步说明本申请方法的各步骤：
S110获取多个权限的安全风险聚类信息。
在本申请实施例中，所述多个权限的安全风险聚类信息为基于安全风险对所述多个权限进行聚类的信息，例如可以包括：多个安全风险分组，例如可以包括：高风险组、中风险组、低风险组；每个安全风险分组中包括的一个或多个权限。其中，属于同一安全风险组的多个权限的安全风险相同或相似。
如图2所示，在本申请实施例一种可能的实施方式中，可以通过下面的方法来获取所述安全风险聚类信息：
S111确定多个应用程序与所述多个权限之间的多个申请关系；其中，所述多个申请关系中的每个申请关系对应于所述多个应用程序中的一应用程序申请所述多个权限中的一权限；
S112确定所述多个申请关系中每个申请关系的权值；
S113根据所述每个申请关系的所述权值对所述多个权限进行安全风险聚类，得到所述安全风险聚类信息。
本实施方式中，通过图2所示的安全风险聚类方法来对多个权限进行安全风险聚类，使得安全风险相似的权限被归为同一安全风险分组中，便于后续步骤基于安全风险对所述多个权限进行的处理。
如图3a所示，在本申请实施例中，发明人考虑到应用程序和权限的特性，提出了基于二部图的模型，来确定应用程序与权限之间的关系。其中，将多个应用程序作为二部图中的第一组节点，将多个权限作为二部图中的第二组节点，两组节点之间的连接由应用程序与权限的申请关系确定，即，当且仅当一应用程序申请了一权限时，所述应用程序与所述权限之间具有申请关系，建立有连接。
下面结合图3a所示的二部图进一步说明本申请实施例的步骤S111～S113：
在本申请实施例中，通过图3a所示的二部图表示本申请实施例多个应用程序与多个权限之间的关系，其中所述二部图G可以表示为：G＝{V，E，W}，其中，
V为节点集，有V＝{V^a，V^p}，
V^a为应用程序集，包括所述多个应用程序a₁～a_M，即V^a＝{a₁，···，a_M}，M为所述多个应用程序的个数，为正整数；
V^p为权限集，包括所述多个权限p₁～p_N，即V^p＝{p₁，···，p_N}；N为所述多个权限的个数，为正整数；
E为申请关系集，其中，当且仅当所述多个应用程序中的一应用程序ai申请了所述多个权限中的一权限p_j时，存在一申请关系e_ij∈E；
W为权值集，一权值w_ij∈W表示所述申请关系e_ij的权值。
如图2所示的实施方式中，二部图包括4个应用程序a₁～a₄，3个权限p₁～p₃，(在图2所示实施例中，所述应用程序a₁～a₄分别为：愤怒的小鸟(游戏类)、切水果(游戏类)、脸谱(社交类)以及麦块(游戏类)；所述权限p1为读取手机状态、权限p2为访问精确位置、权限p3表示读取联系人)；申请关系集包含8个申请关系(图2中通 过应用程序与权限之间的连线表示)：e₁₁，e₁₂，e₂₁，e₂₂，e₃₂，e₃₃，e₄₂以及e₄₃，它们分别对应的权值为0.3，0.7，0.2，0.8，0.5，0.5，0.4以及0.6。
本申请实施例中，所述权值w_ij表示所述应用程序a_i与所述权限p_j的相关性。在一种可能的实施方式中，所述权值w_ij表示所述应用程序a_i申请所述权限p_j的概率。这里应用程序ai申请权限p_j的概率指的是，在确定所述应用程序a_i申请了哪些权限之前，其申请权限p_j的可能性。例如，对于图2中的申请关系e11来说，0.3表示应用程序a₁申请权限p₁的概率为0.3。
当然，在其它可能的实施方式中，所述权值还可以根据其它依据确定，来表示应用程序与权限之间的相关程度，特别的，在一种可能的实施方式中，可以根据用户的设定指令确定所述权值。
如上面所述的，在本申请实施例一种可能的实施方式中，所述步骤S112在确定所述权值时，可以根据所述每个申请关系对应的所述应用程序申请所述权限的概率确定所述每个申请关系的权值。
在本申请实施例中，可以根据历史数据获取所述概率。可选地，在一种可能的实施方式中，可以根据所述每个申请关系对应的所述应用程序所属的一应用分类中所有应用程序的权限申请历史数据确定对应的所述权值。在本实施方式中，所述应用分类可以是根据所述应用程序的功能划分的分类，例如游戏、办公、地图等；还可以是根据应用程序的开发商进行的分类，或者还可以是根据应用程序其它方面的相似性等进行的聚类分类等等。当然，本领域的技术人员可以知道，所述应用分类还可以是其它的分类标准进行的分类。
可选地，在本申请实施例一种可能的实施方式中，可以根据所述应用程序所属的所述应用分类中所有应用程序申请所述权限的频率与所述所有应用程序分别申请所述多个权限的多个频率之和的比值得到所述权值。可以通过下面的公式表示：
wij=fijΣpj∈Vpfij,]]>
其中f_ij表示所述应用程序a_i所属的所述应用分类中的应用程序申请权限p_j的频率。
在本申请实施例一种可能的实施方式中，为了得到归一化的频率，可以通过所述应用分类中申请了一权限的应用程序的数量与该应用分类中所有应用程序的比值得到所述权限对应的所述频率。当然，在本申请实施例其它可能的实施方式中，还可以通过其它方式确定所述频率。
在本申请实施例其它可能的实施方式中，除了上述根据权限的申请频率确定所述每个申请关系的权值外，还可以根据其它参数确定所述权值，例如外部的先验知识，所述先验知识例如可以为本领域专家的意见、其它方法计算出了应用程序与权限之间的相关值等。
可以看出，通过本发明实施例上面的实施方案，可以对多个权限进行基于安全风险的聚类，将安全风险相似的权限划分在同一安全风险分组中，方便用户或应用平台基于安全风险对权限进行后续操作。
可选地，在一种可能的实施方式中，所述步骤S113包括：
获取与所述多个权限一一对应的多个权值向量；
根据所述多个权值向量对所述多个应用程序进行安全风险聚类。
其中，所述多个权值向量中的每个权值向量中包含与所述多个应用程序一一对应的多个元素，对于每个权值向量：
对应于与所述权值向量对应的权限与所述多个应用程序中的一应用程序之间有申请关系，所述权值向量中与所述应用程序对应的元素为所述申请关系的权值；
对应于与所述权值向量对应的权值与所述多个应用程序中的一应用程序之间没有申请关系，所述权值向量中与所述应用程序对应的元素为0。
可以看出，得到的所述多个权值向量中相同位置的元素对应于同 一应用程序，例如，所有权值向量的第一个元素对应于第一个应用程序、第二个元素对应于第二个应用程序…最后一个元素对应于最后一个应用程序。
例如：一权限p_i对应的权值向量表示为其中，所述权值向量包含M个元素，依次分别对应于M个应用程序，其中，当一应用程序申请所述权限p_i时，对应的元素为所述应用程序与所述权限p_i的申请关系的权值；当一应用程序没有申请所述权限p_i时，用0代替该元素(此时可以看成所述应用程序申请所述权限的权值为0)；权限p_j表示为p→j={w1j,...,wMj}.]]>
例如，图3a所示的实施例中，权限p1对应的向量这里的两个0分别表示应用程序a₃和a₄没有申请权限p₁；权限p₂对应的向量p→2={0.7,0.8,0.5,0.5};]]>权限p₃对应的向量p→3={0,]]>0,0.5,0.6}.]]>
可选地，在一种可能的实施方式中，可以根据所述多个权限中两个权限分别对应的权值向量的相似度来对所述多个权限进行安全风险聚类。例如，在所述多个权限中一些权限的安全风险已知的情况下，根据其它权限与这些权限的相似度，可以对所述其它权限进行聚类，进而可以估算该安全风险分组中其它权限的安全风险。
可选地，在一种可能的实施方式中，可以通过两个权限对应的权值向量的余弦距离来确定这两个权限的相似度：
sijp=Cos(p→i,p→j)=p→i·p→j||p→i||·||p→j||]]>
同样的，本领域的技术人员可以知道，其它用于表示两个向量之间相似度的方法也可以用于本申请实施例确定两个权限的相似程度，例如通过两个向量之间的欧式距离或KL距离(Kullback-Leibler Divergence)等来确定所述两个向量的相似度。
可选地，在另一种可能的实施方式中，所述步骤S113在获取了 所述多个权限分别对应的多个权值向量之后，可以通过基于距离的聚类算法对所述多个权值向量进行聚类，进而确定所述多个权限的安全风险聚类。
例如，在一种可能的实施方式中，可以将每个权值向量看成是多维空间中的点(所述多维空间的维度与所述权值向量中的元素个数相等)，通过基于距离的聚类算法，例如通过K-means聚类算法可以对所述多个权值向量进行聚类。当然，本领域技术人员可以知道，其它用于向量的聚类算法也可以应用在本申请实施例中对所述多个权值向量进行聚类，进而对所述多个权限进行聚类。
本领域的技术人员可以知道，上面所述的距离为两个向量之间的距离，例如上面所述的余弦距离、欧式距离等等。
可以看出，通过本发明实施例上面的实施方案，可以对多个权限进行基于安全风险的聚类，将安全风险相似的权限划分在同一权限安全风险分组中，方便用户或开发者基于安全风险对权限进行后续操作。
在本实施方式中，所述方法还可以包括：存储所述安全风险聚类信息。
当然，可选地，本领域技术人员可以知道，在一种可能的实施方式中，在所述安全风险聚类信息已经通过其它步骤或设备等获得的情况下，所述步骤S110还可以为从存储设备读取存储的所述安全风险聚类信息。
S120确定所述多个权限中一应用程序已使用的一权限。
在本申请实施例一种可能的应用场景中，步骤S120中所述应用程序可以为一开发中的应用程序，开发者在开发该应用程序时需要选择使用合适的API。
在该应用场景的一种可能的实施方式中，获取所述已使用的权限包括：
读取当前正在开发的应用程序的配置文件，从相应的权限申请段 中获取应用正在使用的权限。
或者，在另一可能的实施方式中，通过检测当前应用程序已经使用的至少一个API，再根据所述至少一个API获得相对应的权限。
在本申请实施例另一种可能的应用场景中，开发者需要基于一已有应用程序开发一新的应用程序，例如对一已有应用程序进行下一版本的开发，此时步骤S120中所述应用程序也可以为所述已有应用程序。
S130根据所述安全风险聚类信息和所述已使用的权限确定所述多个权限中与所述已使用的权限相关的至少一权限。
如上面所述的，所述安全风险聚类信息包括所述多个权限各自所属的安全风险分组。
在一种可能的实施方式中，所述步骤S130可以包括：
根据所述安全风险聚类信息确定所述已使用的权限所属的一安全风险聚类分组；
根据所述安全风险分组确定所述至少一权限。
在本申请实施例一种可能的实施方式中，所述至少一权限可以为所述安全风险分组中所有的权限，即包括所述已使用的权限。在另一种可能的实施方式中，所述至少一权限可以为所述安全风险分组中除了所述已使用的权限以外的其它权限。
S140根据所述至少一权限确定至少一API。
在本申请实施例中，所述步骤S140包括：
确定与所述至少一权限相关的至少一应用程序，其中，所述至少一应用程序中的每个应用程序申请所述至少一权限中的至少一权限；
获取所述至少一应用程序使用的至少一候选API；
根据设定的至少一确定标准在所述至少一候选API中确定所述至少一API。
在本申请实施例一种可能的实施方式中，所述至少一候选API 可以为所述至少一应用程序使用的所有API。
在另一种可能的实施方式中，所述根据设定的至少一确定标准在所述至少一候选API中确定所述至少一API包括：
获取所述至少一应用程序中的每个应用程序与所述至少一候选API中每个API之间的API使用权值；
获取所述至少一应用程序中的每个应用程序申请所述至少一权限中每个权限的申请关系的权值；
根据所述API使用权值和所述申请关系的所述权值得到所述至少一候选API中每个API的推荐值；
根据所述推荐值确定所述至少一API。
在一种可能的实施方式中，一应用程序与一API之间的API使用权值例如可以通过该应用程序使用了几个API获得，例如，若一个应用程序使用了K个API，则该应用程序与该K个API之间的K个API使用权值皆为1/K。当然，本领域的技术人员可以知道，其它可能的应用程序与API之间的关系对应的值也可以作为所述API使用权值。
在一种可能的实施方式中，可以通过本地分析或者读取获得所述API使用权值，在其它可能的实施方式中，还可以从至少一外部设备获得所述API使用权值。
在一种可能的实施方式中，一应用程序与一权限的申请关系的权值例如可以采用图2和图3a所示实施例中获取的应用程序与权限之间申请关系的权值。
在一种可能的实施方式中，根据所述API使用权值和所述申请关系的权值得到所述每个API的推荐值例如可以为：使用该API的所有应用程序中，获取每个应用程序与所述至少一权限之间对应的申请关系的权值之和与该应用程序与API使用权值之间的乘积，再获得使用该API的所有应用程序的上述乘积之和，具体参见下面针对图3b 所示实施例中对应的描述。
在本实施方式中，根据所述推荐值确定所述至少一API例如可以为：根据所述推荐值对所述至少一候选API进行排序，取排名前N位的N个候选API作为所述至少一API；或者，还可以将推荐值超过一设定推荐阈值的至少一候选API作为所述至少一API。
当然，本领域的技术人员可以知道，还可以根据其它确定标准来确定所述至少一API。例如，在本申请实施例一种可能的实施方式中，所述至少一确定标准例如可以为，所述至少一API为所述至少一候选API。
以图3b所示的应用场景为例，例如，与权限p₁相关的至少一应用程序为应用程序a₁和应用程序a₂；与权限p₁和权限p₂相关的至少一应用程序为应用程序a₁至应用程序a₄。
在本实施方式中，例如，所述至少一权限为图3b所示的四个权限：权限p₁至权限p₄；图3b中只有四个应用程序申请了所述四个权限中的至少一一权限，因此，与所述四个权限相关的应用程序为图3b所示的四个应用程序：应用程序a₁至应用程序a₄；由图3b可以看出，该四个应用程序使用了五个API，分别为：API1～API5。
在本实施方式中，所述应用程序a₁具有与权限p₁和权限p₂之间的两个申请关系，对应的权值分别为0.3和0.7，因此，应用程序a₁的权值之和为1。同样可以得到应用程序a₂的权值之和为0.6；应用程序a₃的权值之和为0.6；应用程序a₄的权值之和为0.4。
应用程序a₁使用了两个API：API1和API2，因此应用程序a₁与API1和API2之间的API使用权值分别为1/2；同样，应用程序a₂与API1、API2以及API3之间的使用权值为1/3；应用程序a₃与API2、API3以及API4之间的使用权值为1/3；应用程序a₄与API3以及API4之间的使用权值为1/2。
因此，可以计算API1的推荐值为：1(应用程序a₁的权值之和) 与1/2(应用程序a₁与API1之间的API使用权值)的乘积加上0.6(应用程序a₂的权值之和)与1/3(应用程序a₂与API1之间的API使用权值)的乘积＝0.7。同样可以得到：
API2的推荐值＝1/2+0.6/3+0.6/3＝0.9；
API3的推荐值＝0.6/3＝0.2；
API4的推荐值＝0.6/3+0.4/2＝0.4。
可以看出API2的推荐值最高，API3的推荐值最低。如果只推荐推荐值最高的API，则本实施方式中所述至少一API为所述API2。
在另一种可能的实施方式中，还可以根据一排序标准对所述至少一API进行排序，以作为其出现在一推荐列表中的顺序。例如，以所述推荐值的大小进行排序。
本领域技术人员可以理解，在本申请具体实施方式的上述方法中，各步骤的序号大小并不意味着执行顺序的先后，各步骤的执行顺序应以其功能和内在逻辑确定，而不应对本申请具体实施方式的实施过程构成任何限定。
如图4所示，本申请实施例一种可能的实施方式提供了一种应用开发接口API推荐装置400，包括：
聚类信息获取模块410，用于获取多个权限的安全风险聚类信息；
已使用权限确定模块420，用于确定所述多个权限中一应用程序已使用的一权限；
相关权限确定模块430，用于根据所述安全风险聚类信息和所述已使用的权限确定所述多个权限中与所述已使用的权限相关的至少一权限；
API确定模块440，用于根据所述至少一权限确定至少一API。
本申请实施例的至少一个实施方案通过一应用程序中已使用的权限来找到与该权限安全风险相似的权限，并根据这些安全风险相似 的权限来得到相关的应用程序所使用的API，进而对应用程序的开发者进行基于安全风险的API推荐。使得集成开发环境可以基于安全风险和功能因素给开发者提供可供选择的API，进而使得开发者可以快速准确的选择具有合适的安全风险和功能的API。
通过下面的实施方式进一步说明本申请实施例的各模块。
在本申请实施例一种可能的实施方式中，所述聚类信息获取模块410获取的所述多个权限的安全风险聚类信息为基于安全风险对所述多个权限进行聚类的信息，例如可以包括：多个安全风险分组，例如可以包括：高风险组、中风险组、低风险组；每个安全风险分组中包括的一个或多个权限。其中，属于同一安全风险组的多个权限的安全风险相同或相似。
如图5a所示，在本申请实施例一种可能的实施方式中，所述聚类信息获取模块410包括：
申请关系确定子模块411，用于确定多个应用程序与所述多个权限之间的多个申请关系；其中，所述多个申请关系中的每个申请关系对应于所述多个应用程序中的一应用程序申请所述多个权限中的一权限；
权值确定子模块412，用于确定所述多个申请关系中每个申请关系的权值；
聚类信息获取子模块413，用于根据所述每个申请关系的所述权值对所述多个权限进行安全风险聚类，得到所述安全风险聚类信息。
本申请实施例的所述申请关系确定子模块411通过基于一二部图的模型确定所述多个应用程序和多个权限之间的关系。具体参见图2所示方法实施例中对应的描述。
在本申请实施例一种可能的实施方式中，对于所述多个应用程序与多个权限之间的多个申请关系以及每个申请关系对应的权值的进一步描述参见上述方法实施例中对图3a所示实施方式的描述，这里 不再赘述。
在本申请实施例中，所述申请关系的权值对应于所述申请关系对应的应用程序与权限之间的相关性，一般来说，所述相关性越强，所述权值的大小越大。因此，所述权值确定子模块412根据所述应用程序与权值之间的相关性就可以确定所述权值的大小。
在一种可能的实施方式中，可以通过所述应用程序申请所述权限的概率的大小来获得所述相关性。当然，本领域的技术人员可以知道，在其它可能的实施方式中，除了所述概率外，还可以通过其它方式确定所述应用程序与权限之间的相关性。
可选地，如图5b所示，在一种可能的实施方式中，所述权值确定子模块412包括：
第一权值确定单元4121，用于根据所述每个申请关系对应的所述应用程序申请所述权限的概率确定所述每个申请关系的权值。
在本申请实施例一种可能的实施方式中，可以根据历史数据获取所述概率。例如，如图5c所示，在一种可能的实施方式中，所述权值确定子模块412包括：
第二权值确定单元4122，用于根据所述每个申请关系对应的所述应用程序所属的一应用分类中所述所有应用程序申请所述权限的频率与所述所有应用程序分别申请所述多个权限的多个频率之和的比值得到所述权值。具体参见图3a所示方法实施例中对应的描述。
在本申请实施例一种可能的实施方式中，为了得到归一化的频率，可以通过所述应用分类中申请了一权限的应用程序的数量与该应用分类中所有应用程序的比值得到所述权限对应的所述频率。当然，在本申请实施例其它可能的实施方式中，还可以通过其它方式确定所述频率。
在本实施方式中，所述应用分类可以是根据应用程序的功能划分的分类，例如游戏、办公、地图等；还可以是根据应用程序的开发商 进行的分类，或者还可以是根据应用程序其它方面的相似性等进行的聚类分类等等。当然，本领域的技术人员可以知道，所述应用分类还可以是以其它的分类标准进行的分类。
如图5b所示，在一种可能的实施方式中，所述聚类信息获取子模块413包括：
权值向量获取单元4131，用于获取与所述多个权限一一对应的多个权值向量；
其中，所述多个权值向量中的每个权值向量中包含与所述多个应用程序一一对应的多个元素，其中，对于每个权值向量：
对应于与所述权值向量对应的权限与所述多个应用程序中的一应用程序之间有申请关系，所述权值向量中与所述应用程序对应的元素为所述申请关系的权值；
对应于与所述权值向量对应的权值与所述多个应用程序中的一应用程序之间没有申请关系，所述权值向量中与所述应用程序对应的元素为0。
在本实施方式中，所述聚类信息获取子模块413还包括：
权限聚类单元4132，用于根据所述多个权值向量对所述多个应用程序进行安全风险聚类。
可以看出，得到的所述多个权值向量中相同位置的元素对应于同一应用程序，例如，所有权值向量的第一个元素对应于第一个应用程序、第二个元素对应于第二个应用程序…最后一个元素对应于最后一个应用程序。具体参见上面方法实施例中对应的描述。
可选地，如图5d所示，在一种可能的实施方式中，所述权限聚类单元4132包括：
第一聚类子单元4132a，用于根据所述多个权限中两个权限分别对应的权值向量的相似度来对所述多个权限进行安全风险聚类。
例如，在所述多个权限中一些权限的安全风险已知的情况下，根 据其它权限与这些权限的相似度，可以对所述其它权限进行聚类，进而可以估算该权限安全风险分组中其它权限的安全风险。
可选地，在一种可能的实施方式中，可以通过两个权限对应的权值向量的余弦距离来确定这两个权限的相似度。具体参见上述方法实施例中对应的描述。
同样的，本领域的技术人员可以知道，其它用于表示两个向量之间相似度的方法也可以用于本申请实施例确定两个权限的相似程度，例如上面所述的欧式距离。
可选地，如图5e所示，在一种可能的实施方式中，所述权限聚类单元4132包括：
第二聚类子单元4132b，用于通过基于距离的聚类算法对所述多个权值向量进行聚类，进而确定所述多个权限的安全风险聚类。
例如，在一种可能的实施方式中，可以将每个权值向量看成是多维空间中的点(所述多维空间的维度与所述权值向量中的元素个数相等)，通过基于距离的聚类算法，例如通过K-means聚类算法可以对所述多个权值向量进行聚类。当然，本领域技术人员可以知道，其它用于向量的聚类算法也可以应用在本申请实施例中对所述多个权值向量进行聚类，进而对所述多个权限进行聚类。
本领域的技术人员可以知道，上面所述的距离为两个向量之间的距离，例如上面所述的余弦距离、欧式距离等等。
可以看出，通过本发明实施例上面的实施方案，可以对多个权限进行基于安全风险的聚类，将安全风险相似的权限划分在同一权限安全风险分组中，方便用户或开发者基于安全风险对权限进行后续操作。
如图6a所示，在一种可能的实施方式中，所述装置400还包括：
存储模块450，用于存储所述安全风险聚类信息。
当然，可选地，本领域技术人员可以知道，在一种可能的实施方式中，在所述安全风险聚类信息已经通过其它设备获得的情况下，所述聚类信息获取模块410还可以用于从所述存储模块450读取存储的 所述安全风险聚类信息。
在本申请实施例一种可能的应用场景中，所述已使用权限确定模块420确定所述已使用的权限时，所述应用程序可以为一开发中的应用程序，开发者在开发该应用程序时需要选择使用合适的API。
在该应用场景的一种可能的实施方式中，如图6a所示，所述已使用权限确定模块420获取所述已使用的权限包括：
配置文件分析单元421，用于读取当前正在开发的应用程序的配置文件，从相应的权限申请段中获取应用正在使用的权限。
或者，在另一可能的实施方式中，如图6b所示，所述已使用权限确定模块420包括：
已使用API获取单元422，通过获取当前应用程序已经使用的至少一个API，再根据所述至少一个API获得相对应的权限。
在本申请实施例另一种可能的应用场景中，开发者需要基于一已有应用程序开发一新的应用程序，例如对一已有应用程序进行下一版本的开发，此时所述应用程序也可以为所述已有应用程序。
如上面所述的，所述安全风险聚类信息包括所述多个权限各自所属的安全风险分组。因此，如图6a所示，在一种可能的实施方式中，所述相关权限确定模块430包括：
安全风险分组确定子模块431，用于根据所述安全风险聚类信息确定所述已使用的权限所属的一安全风险分组；
相关权限确定子模块432，用于根据所述安全风险分组确定所述至少一权限。
在本申请实施例一种可能的实施方式中，所述至少一权限可以为所述安全风险分组中所有的权限，即包括所述已使用的权限。在另一种可能的实施方式中，所述至少一权限可以为所述安全风险分组中除了所述已使用的权限以外的其它权限。
如图6c所示，在一种可能的实施方式中，所述API确定模块440 包括：
应用程序确定子模块441，用于确定与所述至少一权限相关的至少一应用程序；
候选API确定子模块442，用于获取所述至少一应用程序使用的至少一候选API；
API确定子模块443，用于根据设定的至少一确定标准在所述至少一候选API中确定所述至少一API。
其中，所述应用程序确定子模块441确定的所述至少一应用中的每个应用程序申请所述至少一权限中的至少一权限。
在本申请实施例一种可能的实施方式中，候选API确定子模块443可以确定所述至少一候选API可以为所述至少一应用程序使用的所有API。
如图6d所示，在另一种可能的实施方式中，所述候选API确定子模块443包括：
API使用权值获取单元4431，用于获取所述至少一应用程序中的每个应用程序与所述至少一候选API中每个API之间的API使用权值；
申请关系权值获取单元4432，用于获取所述至少一应用程序中的每个应用程序申请所述至少一权限中每个权限的申请关系的权值；
推荐值获取单元4433，用于根据所述API使用权值和所述申请关系的所述权值得到所述至少一候选API中每个API的推荐值；
API确定单元4434，用于根据所述推荐值确定所述至少一API。
所述API确定模块440中各子模块和单元的功能实现参见上述方法实施例中图3b所示实施例中对应的描述，这里不再赘述。
如图7所示，在本申请实施例一种可能的实施方式中提供了一种电子设备700，包括上面所述的API推荐装置710。
其中，在一种可能的实施方式中，所述电子设备700可以为一服务器，可选地，例如为一开发平台的服务器。
图8为本申请实施例提供的又一种API推荐装置800的结构示意图，本申请具体实施例并不对API推荐装置800的具体实现做限定。如图8所示，该API推荐装置800可以包括：
处理器(processor)810、通信接口(Communications Interface)820、存储器(memory)830、以及通信总线840。其中：
处理器810、通信接口820、以及存储器830通过通信总线840完成相互间的通信。
通信接口820，用于与比如客户端等的网元通信。
处理器810，用于执行程序832，具体可以执行上述方法实施例中的相关步骤。
具体地，程序832可以包括程序代码，所述程序代码包括计算机操作指令。
处理器810可能是一个中央处理器CPU，或者是特定集成电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。
存储器830，用于存放程序832。存储器830可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。程序832具体可以用于使得所述API推荐装置800执行以下步骤：
获取多个权限的安全风险聚类信息；
确定所述多个权限中一应用程序已使用的一权限；
根据所述安全风险聚类信息和所述已使用的权限确定所述多个权限中与所述已使用的权限相关的至少一权限；
根据所述至少一权限确定至少一API。
程序832中各步骤的具体实现可以参见上述实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上实施方式仅用于说明本申请，而并非对本申请的限制，有关技术领域的普通技术人员，在不脱离本申请的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本申请的范畴，本申请的专利保护范围应由权利要求限定。