A Diverse API Recommendation Method Based on Association Graph

Abstract

The present invention belongs to the field of API recommendation, and specifically relates to a method for recommending diverse APIs based on an association graph, comprising: constructing a depopularized API association graph; obtaining candidate API combinations that meet development requirements by finding the minimum weighted subgraph; constructing a kernel matrix based on the feature vectors of each candidate API combination, solving the kernel matrix using a fast greedy MAP inference algorithm, and finding the API combination that maximizes the posterior probability from the candidate API combinations to obtain a recommendation result. The present invention constructs a depopularized API association graph based on the functional description keywords of the API and the historical interaction data between the mashup and the API. Based on the depopularized API association graph, the API recommendation problem is modeled as a problem of finding the minimum weighted subgraph to obtain a depopularized API combination that meets development requirements, has compatibility, and is depopularized, so that the recommendation results are depopularized while maintaining compatibility and meeting development requirements.

Description

Technical Field

[0001] The present invention belongs to the field of API recommendation, and in particular relates to a diversity API recommendation method based on an association graph. Background Art

[0002] Today's society has entered the era of cloud computing and big data. Mobile internet, the Internet of Things, cloud computing, and big data are experiencing rapid growth within this era, and a growing number of internet providers are beginning to serve users through services. However, as the internet continues to evolve, business scenarios are becoming more complex, and existing single services no longer meet user needs.

[0003] With the growing popularity of service-oriented computing (SOC) and service-oriented architecture (SOA), more and more modern enterprises and organizations are publishing their business functions as publicly accessible services (or APIs) to address the cross-border integration and innovative development of information service technologies. In this environment, a key technology has emerged to meet complex needs by integrating multiple services: mashup technology. Mashup technology can combine the latest, easy-to-use APIs to create a brand new application. Due to its advantages, the number of APIs is growing rapidly and exponentially. According to data from ProgrammableWeb (an online web API sharing platform) alone (from June 2011 to March 2018), the number of APIs increased from 3,261 to over 19,000, a 500% increase. Mashup developers face challenges in finding the right APIs to meet all their needs quickly, which undoubtedly increases the complexity of mashup development. API recommendation has attracted attention from both the business and academic communities because it helps developers quickly and efficiently find APIs that meet comprehensive requirements during mashup development.

[0004] In the real world, developers can use online Web API sharing platforms, such as ProgrammableWeb.com (PW), to browse and select suitable APIs by entering keywords reflecting their requirements into the search bar. These APIs can then be assembled into a mashup that meets their functional requirements. However, a single keyword can return hundreds or even thousands of APIs, requiring developers to spend a significant amount of time sifting through them. API recommendations, using data from online API sharing platforms, can directly recommend APIs that meet their requirements to developers, significantly streamlining the mashup development process.

[0005] With the continuous development of the API recommendation field, many current API recommendation methods can provide developers with highly accurate recommendations based on data from online API sharing platforms. These accuracy-focused API recommendation methods generally make recommendations based on functional characteristics. Specifically, they measure the similarity between API documents and use techniques such as matrix decomposition and factorization machines to recommend the most similar APIs to meet user needs. While these methods improve the accuracy and efficiency of prediction and recommendation to a certain extent, API recommendations based solely on functional characteristics cannot guarantee the compatibility of recommended results.

[0006] Therefore, a growing number of API recommendation methods are focusing on the non-functional characteristics of APIs, specifically exploring historical API call patterns. The co-occurrence counts between mashups and API call history provide a good indicator of API compatibility. To better understand API compatibility, many researchers are turning their attention to graph structures, which can more fully describe the relationships between nodes. These graph-based methods have demonstrated strong compatibility and, with continued development, have also seen increasing accuracy. However, they often overlook the diversity of recommendations, limiting the scope for developer exploration.

[0007] Currently, online API sharing platforms face a widespread problem: a severe long-tail distribution of APIs. Interaction data between APIs and mashups shows that only a few APIs are frequently called, while the majority are never even called by a mashup. Consequently, recommendations based on this data often result in a few popular APIs being consistently recommended, while the majority are never recommended at all. Highly popular APIs appear more frequently in developers' choices, leading to popularity bias and unfair recommendation results. On the other hand, developers are showing increasing interest in long-tail services, demonstrating their desire to explore and try out a variety of services. However, the invariable presence of popular APIs in recommendation results results in a lack of diversity in the API choices available to developers. Summary of the Invention

[0008] To solve the above technical problems, the present invention proposes a method for recommending diverse APIs based on an association graph, comprising the following steps:

[0009] S1: Obtain the original data from the ProgrammableWeb dataset and preprocess the original data to form a new dataset;

[0010] The original data includes: API function description keywords, historical call records of mashup to API, and mashup developer's function requirement keywords;

[0011] S2: Based on the API function description keywords and the historical call records of the mashup to the API, a depopularized API association graph is constructed to reflect the API function, compatibility and popularity deviation;

[0012] S3: Based on the functional requirement keywords of mashup developers, the method of finding the minimum weighted subgraph in the depopularized API association graph is used to obtain candidate API combinations that meet the development requirements, and the candidate API combination set L is obtained;

[0013] S4: Use Word2Vec to embed each candidate API combination into a low-dimensional feature vector to obtain the feature vector of the API combination, and construct the kernel matrix L according to the feature vector of each candidate API combination. A , using the fast greedy MAP inference algorithm to solve the kernel matrix L A , find the API combination that can maximize the posterior probability from the candidate API combination and form a subset of size K Get the Top-K API combination recommendation list

[0014] Beneficial effects of the present invention:

[0015] Based on API function description keywords and historical interaction data between mashups and APIs, this paper constructs a de-popularized API association graph that reflects API functionality, compatibility, and popularity. Based on this de-popularized API association graph, the API recommendation problem is modeled as finding a minimum weighted subgraph problem to obtain a de-popularized API combination that meets development requirements, is compatible, and is de-popularized. This allows the recommendation results to de-popularize while maintaining compatibility and meeting development requirements.

[0016] After obtaining the API combination recommendations that satisfy functional requirements, are compatible with each other, and are also popular, the present invention further rearranges the recommendation results to make the recommended API combinations more diversified. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flow chart of a diversity API recommendation method based on an association graph according to the present invention;

[0018] Figure 2 This is an example of an API association graph without popularity of the present invention;

[0019] Figure 3 This is a schematic diagram of the process of finding the minimum weighted subgraph of the present invention;

[0020] Figure 4 Schematic diagram of feature vector rearrangement of the API combination of the present invention. DETAILED DESCRIPTION

[0021] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0022] A diverse API recommendation method based on association graph, such as Figure 1 Shown, including:

[0023] S1: Obtain the original data from the ProgrammableWeb dataset and preprocess the original data to obtain a new dataset;

[0024] The original data includes: API function description keywords, historical call records of mashup to API, and demand keywords of mashup developers;

[0025] S2: Based on the API function description keywords and the historical interaction data between the mashup and the API, a de-popularized API association graph is constructed to reflect the API function, compatibility, and popularity deviation;

[0026] S3: Based on the functional requirement keywords of mashup developers, the method of finding the minimum weighted subgraph in the depopularized API association graph is used to obtain candidate API combinations that meet the development requirements, and the candidate API combination set L is obtained;

[0027] S4: Use Word2Vec to embed each candidate API combination into a low-dimensional feature vector to obtain the feature vector of the API combination, and construct the kernel matrix L according to the feature vector of each candidate API combination. A , using the fast greedy MAP inference algorithm to solve the kernel matrix L A , find the API combination that can maximize the posterior probability from the candidate API combination and form a subset of size K Get the Top-K API combination recommendation list

[0028] The dataset used is ProgrammableWeb, which contains 17,829 APIs, 6,340 mashups, and 10,737 historical call records.

[0029] like Figure 2 As shown in the figure, a de-popularized API association graph is constructed based on the API function description keywords and the historical interaction data between the mashup and the API:

[0030] Definition 1. Vertex (API and vertex are interchangeable in this paper). For each API in the ProgrammableWeb dataset, it is defined as the vertex v in the API association graph without popularity. i ∈V(1≤i≤n,|V|=n), each API has a set of keywords that can reflect its own functional description

[0031] like Figure 2 As shown in , there are 5 vertices V = {v1, v2, ..., v5}, representing 5 APIs, where v5 represents API A5 containing 3 functional keywords kq2, kq6 and kq9;

[0032] Definition 2. Edge: If two APIs are called by a mashup together, their vertices are connected by an undirected edge, which means that the two APIs are compatible with each other. Define the edge as e(v i ,v j )∈E(1≤i,j≤n, E represents the edge set);

[0033] For example Figure 2 If e(v1,v4) exists, it means that API A1 and A4 have been called together and are compatible with each other. If e(v3,v4) does not exist, it means that API A3 and A4 have not been called together and cannot be compatible with each other.

[0034] Definition 3. Vertex weight. The popularity of an API is defined as the ratio of the number of mashups that have called the API to the total number of mashups. The popularity of each API is the weight of the vertex, that is, VW represents the weight set of vertices;

[0035] like Figure 2 The vw of v2 is The vertex weight of v2 is It has been called by 3 out of 5 mashups. The smaller the vertex weight, the less popular the API represented by the vertex.

[0036] Definition 4. Edge weight. The edge weight is defined as the number of times two APIs are called together, and the inverse is used for normalization, that is, (y is the number of times two APIs are called together, and EW represents the edge weight set of the APIs that are called together);

[0037] For example Figure 2 The ew of e(v2,v5) is The weight representing e(v2,v5) is The smaller the edge weight, the more compatible the APIs represented by the two vertices of the edge are;

[0038] Definition 5. API association graph without popularity. Using V, E, VW, and EW obtained above, DP-ACG can be defined as a graph.

[0039] After obtaining the API association graph without popularity, we can select APIs that meet the conditions in the API association graph without popularity to form a subgraph based on the demand keywords entered by the developer. Each subgraph is a candidate API combination.

[0040] like Figure 3 As shown, it is assumed that the set of functional requirement keywords of developers is Q = {q1,q2,...,q I}, according to the function keyword set of the vertices in Q and G, we can select the vertex v in G that intersects with Q i (1≤i≤n), its function keyword set Need to meet Then ov i =[v i ](1≤i≤n), like Then v i It is a candidate API combination L that meets development needs l =[v i ](1≤l≤N). Through the above steps, we can get a vertex array OV=[ov i ,...,ov j ](1≤i,j≤n), a keyword array

[0041] Then according to OV=[ov i ,...,ov j ]and Select the neighboring points that satisfy. Specifically, find ov in G i The neighbor point v of the vertex x ∈V(1≤x≤n), each ov i There is a corresponding neighbor point array neiv i =[v x ,...,v y ](1≤i,x,y≤n) and the function keyword array of neighbor points So find the neighbor point array Neiv of OV = [neiv i ,...,neiv j ](1≤i,j≤n) and the function array of neighbor points

[0042] After getting OV, K, Neiv and NK, we can start to build the subgraph. If the keywords of the vertex and neighbor points meet the development requirements (i.e. ) then a candidate API combination L is directly obtained without composition l =[v i ,v x ](1≤l≤N), otherwise start to build the subgraph g(gv,ge); when building the subgraph, first consider the neighboring points that have an intersection with the remaining demand functions (i.e. ), at this time gv i =[v i ,v x ],ge f ={e(v i ,v x )}(1≤f≤|neiv i |,|neiv i | represents the number of neighbor points of a vertex), The weight of the subgraph g(w,gv,ge) is w. If all the neighboring points of a vertex have no intersection with the remaining functions, then a neighboring point is selected so that the weight w of the subgraph formed by the neighboring point and the vertex is the smallest. In this way, the subgraph g is continuously constructed and then it is judged whether the demand keywords of g cover all the demand function sets Q until L = {L1,L2,...,L l}(l=N).

[0043] The calculation formula of weight w is as follows:

[0044] w(g)=VW gv +EW ge

[0045] Among them, w(g) represents the weight of subgraph g, VW gv Represents the sum of all vertex weights in the vertex set gv in the subgraph g, EW ge Represents the sum of all edge weights in the edge set ge in the subgraph g.

[0046] like Figure 4 As shown in the figure, Word2Vec is used to embed each candidate API combination into a low-dimensional feature vector as input for achieving diversified combination recommendation rearrangement.

[0047] After obtaining the feature vector of each candidate API combination, it is necessary to construct the kernel matrix L A , as shown in the following formula:

[0048] L A =Diag(C Q )·C S Diag(C Q )

[0049] Among them, C Q is a diagonal matrix C Q =diag(c1,...,c N ), which reflects the quality profile of the candidate API combinations, where N is the number of selected candidate API combinations, c x (1≤x≤N) is the normalized weight of the i-th candidate API combination, c x It can be calculated:

[0050]

[0051] Among them, W x , W y are the weights of the xth candidate API combination and the yth candidate API combination (1≤x,y≤N), C S is the similarity matrix C S =[sim xy ](where the elements on the diagonal are 1, i.e. sim xx =1), which reflects the similarity between candidate API combinations; xy (0<x,y<N,x≠y) The normalized feature vector NVector of the x-th candidate API combination and the y-th candidate API combination x With NVector y The inner product is calculated; and the feature vector vector of the lth candidate API combination l (1≤l≤N) can be obtained by the following formula:

[0052]

[0053] Among them, L l ∈L represents the lth candidate API combination, Represents the embedded feature vector of the i-th API in the l-th candidate API combination, followed by the normalized feature vector Nvector of the l-th candidate API combination l (||Nvector l ||2=1,1≤l≤N) can be calculated by the following formula:

[0054]

[0055] Successfully constructed kernel matrix L A After that, we can further find a subset of size K of API combinations that can maximize the posterior probability from the candidate API combinations. But it remains a difficult problem.

[0056] In order to overcome the huge computational complexity brought by directly solving the MAP estimation, a fast greedy MAP inference algorithm is used to solve the kernel matrix to obtain the final Top-K API combination recommendation list.

[0057] A fast greedy MAP inference algorithm is used to find the final Top-K API combination recommendation list from the candidate API combination L, including:

[0058] FL=arg max FL∈L,|FL|＝K logdet((L A ) FL )

[0059] Among them, FL represents the API combination recommendation list, L represents the candidate API combination set, K represents the number of API combinations in the API combination recommendation list, and L A represents the kernel matrix.

[0060] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A diversity API recommendation method based on association graph, characterized in that: include: S1: Obtain the original data from the ProgrammableWeb dataset and preprocess the original data to form a new dataset; The original data includes: API function description keywords, historical call records of mashup to API, and mashup developer's function requirement keywords; S2: Based on the API function description keywords and the historical call records of the mashup to the API, a depopularized API association graph is constructed to reflect the API function, compatibility and popularity deviation; S3: Based on the functional requirement keywords of mashup developers, the method of finding the minimum weighted subgraph in the depopularized API association graph is used to obtain candidate API combinations that meet the development requirements, and the candidate API combination set L is obtained; Based on the functional requirement keywords of mashup developers, we use the method of finding the minimum weighted subgraph in the depopularized API association graph to obtain candidate API combinations that meet development requirements, including: According to the functional requirements of mashup developers, the keyword set Q = {q1,q2,...,q I } and the function keyword set of the vertex in the popularity API association graph G, select the vertex whose function keyword in the popularity API association graph G intersects with the set Q, and its function keyword set satisfies that the intersection with the set Q is not an empty set. If its function keyword set is equal to the set Q, then there is only one vertex that meets the development requirements. Through screening, a vertex array OV and a keyword array OK are obtained; According to the vertex array OV and the keyword array OK, find the vertex ov in the vertex array OV in the popularity API association graph G. i Neighbor point v x , each vertex ov i There is a corresponding neighbor point array neiv i =[v x ,...,v y ] and the function keyword array of neighbor points Get the neighbor point array Neiv of the vertex array OV = [neiv i ,...,neiv j ] and the function keyword array of neighbor points Construct a subgraph based on the vertex array OV, keyword array OK, neighbor point array Neiv and neighbor point function keyword array NK to obtain the candidate API combination: If the keywords of the vertex and neighbor point meet the development requirements, a candidate API combination L is directly obtained without composition. l =[v i ,v x ], otherwise start to build the subgraph g(gv,ge), where gv represents the vertex of the subgraph and ge represents the edge of the subgraph. When building the subgraph, first consider the neighboring points that have intersections with the remaining functional requirements. At this time, vertex v i and its neighbor point v x The vertices that make up the subgraph gv i =[v i ,v x ], vertex v i and its neighbor point v x The edges that make up the subgraph f ={e(v i ,v x )},|neiv i | represents the number of neighbor points of a vertex, 1≤f≤|neiv i |, vertex v i and its neighbor point v x Requirement keywords that constitute the subgraph The weight of the subgraph g(w,gv,ge) is w. If all the neighboring points of a vertex have no intersection with the remaining functional requirements, then a neighboring point is selected to satisfy the minimum weight w of the subgraph formed by the neighboring point and the vertex. The subgraph g is constructed repeatedly, and then it is determined whether the demand keywords of the subgraph g cover all the demand function sets Q. When the demand keywords of the subgraph g cover all the demand function sets Q, the candidate API combination set L={L1,L2,...,L l ,...L N }; S4: Use Word2Vec to embed each candidate API combination into a low-dimensional feature vector to obtain the feature vector of the API combination, and construct the kernel matrix L according to the feature vector of each candidate API combination. A , using the fast greedy MAP inference algorithm to solve the kernel matrix L A , find the API combination that can maximize the posterior probability from the candidate API combination and form a subset of size K Get the Top-K API combination recommendation list 2. The method for recommending diverse APIs based on an association graph according to claim 1, characterized in that: Based on the API function description keywords and the historical call records of the mashup to the API, a depopularized API association graph is constructed to reflect the API function, compatibility, and popularity deviation, including: Define each API as a vertex v in the API association graph without popularity i ∈V, each API has a set of keywords that can reflect its own functional description Where V represents the vertex set, Represents vertex v i Keyword collection, kq x Represents vertex v i The xth keyword, kq j Represents vertex v i The jth keyword of If two APIs are called by a mashup together, there is an undirected edge connecting them, indicating that the two APIs are compatible with each other. The edge is defined as e(v i ,v j )∈E, where E represents the edge set, e(v i ,v j ) represents the vertex v i With vertex v j The edges of the composition; The popularity of an API is defined as the ratio of the number of mashups that have called the API to the total number of mashups. The popularity of each API represents the weight vw of the vertex. Where x represents the number of mashups that have called the API, m represents the total number of API mashups, and VW represents the weight set of vertices; The edge weight is defined as the number of times two APIs are called together, and the edge weight is obtained by normalizing the inverse. Where ew represents the edge weight of the two APIs that are called together, y represents the number of times the two APIs are called together, and EW represents the edge weight set of the APIs that are called together; According to the obtained vertex set V, edge set E, vertex weight set VW, and edge weight set EW, DP-ACG is defined as a graph, and the depopularized API association graph G that can reflect API functions, compatibility and popularity deviation is obtained.

3. The method for recommending diverse APIs based on association graphs according to claim 1, characterized in that: The weight of the subgraph, including: in(g)=VW gv +EW ge , Among them, w(g) represents the weight of subgraph g, VW gv Represents the sum of all vertex weights in the vertex set gv in the subgraph g, EW ge Represents the sum of all edge weights in the edge set ge in the subgraph g.

4. The method for recommending diverse APIs based on association graphs according to claim 1, wherein: Construct the kernel matrix L A : L A =Diag(C Q )·C S ·Diag(C Q ) Among them, L A represents the kernel matrix, and C Q represents the diagonal matrix reflecting the quality profile of the candidate API combinations, and C Q = diag(c1,..., c N ), N represents the number of selected candidate API combinations, and c x represents the normalized weight of the x-th candidate API combination, where 1 ≤ x ≤ N. W x , W y respectively represent the weights of the x-th and y-th candidate API combinations; C S represents the similarity matrix reflecting the similarity between candidate API combinations, and C S = [sim xy , where sim xy represents the element of the similarity matrix calculated from the inner product of the normalized feature vectors NVector x of the x-th and y-th candidate API combinations and NVector y , where 0 < x, y < N, x ≠ y, and N represents the number of candidate API combinations.

5. The method for recommending diverse APIs based on association graphs according to claim 1, characterized in that: A fast greedy MAP inference algorithm is used to find the final Top-K API combination recommendation list from the candidate API combination L, including: FL=argmax FL∈L,|FL|＝K logdet((L A ) FL ) Among them, FL represents the API combination recommendation list, L represents the candidate API combination set, K represents the number of API combinations in the API combination recommendation list, and L A represents the kernel matrix.

Images