API (Application Program Interface) combination recommendation method and device, equipment and storage medium

Abstract

The invention provides an API combination recommendation method and device, equipment and a storage medium, and belongs to the technical field of data processing, and the method comprises the steps: obtaining the function description and historical call records of each API in mashup, and determining the relation weight between the APIs based on the historical call records; constructing an API relation graph by taking each API as a node, taking the function description as a node label and taking the relation weight as the weight of the edge between the nodes; obtaining a function demand keyword provided by a mashup developer, and constructing a query graph by taking the function demand keyword as a node tag; sub-graphs isomorphic to the query graph are retrieved in the API relation graph, and candidate sub-graphs are obtained; adding the weights of the edges in each candidate sub-graph, and calculating a weight score; and sorting the sub-graphs based on the weight scores, and selecting the API combinations in the first k sub-graphs as target combinations for recommendation. According to the method, the accuracy of API combination recommendation can be improved, so that the performance of mashup is improved.

Description

Technical Field

[0001] The present invention belongs to the field of data processing technology, and specifically relates to an API combination recommendation method, device, equipment and storage medium. Background Art

[0002] With the rapid development of the Application Programming Interface (API) economy, many online API sharing repositories have emerged. In these shared repositories, there are a large number of reusable and programmable APIs that can be used for external calls, which allows developers to browse and evaluate potentially useful WebAPIs from the repository, and then quickly create the required target API combination. However, due to the rapid increase in the number and types of Web APIs, a large number of Web APIs with similar functions have emerged, making it difficult for mobile application developers to select appropriate Web APIs for research, resulting in information overload. In this context, it has become a vital task to recommend compatible and accurate Web API combination solutions to mashup (Web sites or Web applications that aggregate content from one or more information sources) developers based on their specific needs.

[0003] The existing recommendation methods mainly query APIs that meet the functions based on multiple functional keywords entered by users, and then recommend combinations of the multiple APIs found. This method can only provide functionally related API combinations without considering the compatibility between these APIs. If there are incompatibilities between the APIs in the recommended API combination, the overall performance of the mashup will be affected. Summary of the invention

[0004] In order to solve the problem of inaccurate API combination recommendation in the prior art, the present invention provides an API combination recommendation method, device, equipment and storage medium.

[0005] In order to achieve the above object, the present invention provides the following technical solutions: An API combination recommendation method includes: Obtain the function description and historical call records of each API in the mashup, and determine the relationship weights between each API based on the historical call records. The relationship weights are used to characterize the compatibility between APIs. Consider each API as a node, use the function description as the node label, and use the relationship weight as the weight of the edge between nodes to build an API relationship graph; obtain the function requirement keywords provided by mashup developers, use the function requirement keywords as node labels, and build a query graph; Retrieve the subgraphs that are isomorphic to the query graph in the API relationship graph to obtain candidate subgraphs; sum the weights of the edges in each candidate subgraph to calculate the weight score; The subgraphs are sorted based on the weight scores, and the API combinations in the top k subgraphs are selected as the target combinations for recommendation, where k is an integer greater than or equal to 1.

[0006] Optionally, the relationship weights between the APIs are determined based on historical call records, including: Determine the number of times any two APIs are called together by the same mashup based on historical call records; The relationship weights between APIs are determined based on the number of common calls. The formula for calculating the relationship weights is: ; in, Representation API and API The number of times it is called by the mashup. Representation Node and The edge weights between The smaller the API and API The better the compatibility.

[0007] Optionally, a subgraph isomorphic to the query graph is retrieved in the API relationship graph by using a subgraph matching algorithm to obtain a candidate subgraph, including: Traverse the API relationship graph for each node u' in the query graph and generate a candidate set that matches the node u'. The labels of the nodes in the candidate set are the same as the label of the node u'. Select an unmapped node in the query graph as the starting node, select a candidate node from the candidate set of the starting node for mapping; push the current mapping and the remaining unmapped nodes in the query graph into a stack; If the remaining unmapped nodes in the stack are empty, perform isomorphism verification to check whether the mapped subgraph has the same topological structure and label as the query graph; the subgraph that passes the verification is used as a candidate subgraph; If the verification fails or there are still unmapped nodes, an unmapped node is selected and a candidate node is selected from the corresponding candidate set for mapping. The new mapping and the updated remaining nodes are pushed into the stack again until the stack is empty.

[0008] Optionally, for each node u' in the query graph, traverse the API relationship graph to generate After the matching candidate set, it also includes: The candidate set is pruned by label constraints, neighbor constraints, and degree constraints.

[0009] The present invention also provides an API combination recommendation device, comprising: The acquisition module is used to obtain the function description and historical call records of each API in the mashup, and determine the relationship weights between each API based on the historical call records. The relationship weights are used to characterize the compatibility between APIs. A construction module is used to construct an API relationship graph by treating each API as a node, using the function description as the node label, and using the relationship weight as the weight of the edge between nodes; obtaining the function requirement keywords provided by mashup developers, using the function requirement keywords as node labels, and constructing a query graph; A search module is used to retrieve a subgraph isomorphic to the query graph in the API relationship graph to obtain a candidate subgraph; the weights of the edges in each candidate subgraph are summed to calculate a weight score; The recommendation module is used to sort the subgraphs based on the weight scores and select the API combinations in the top k subgraphs as the target combinations for recommendation.

[0010] The present invention also provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned API combination recommendation method when executing the program.

[0011] The present invention also provides a computer-readable storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned API combination recommendation method is implemented.

[0012] The API combination recommendation method provided by the present invention has the following beneficial effects: In the present invention, the relationship weights between various APIs are determined according to the historical call records of various APIs in the mashup; each API is regarded as a node, the function description is used as the node label, and the relationship weight is used as the weight of the edge between nodes to construct an API relationship graph; a query graph is constructed according to the functional requirements of mashup developers, a subgraph isomorphic to the query graph is retrieved in the API relationship graph, and API combination recommendations are made according to the weight scores of the subgraphs; since the relationship weights are used to characterize the compatibility between APIs, the API relationship graph is constructed by using the relationship weights as the weights of the edges between nodes, which can reflect the compatibility between various APIs in the API relationship graph, and further, the query graph is constructed by using the functional requirements of the development as the node labels and searching in the API relationship graph so that the functions of each node in the retrieved subgraph meet the development requirements; API combination recommendations are made according to the weight scores of the subgraphs, so that the nodes in the recommended API combination are compatible. Therefore, when considering whether the API functions meet the requirements, the present invention further considers the compatibility between various APIs, realizes more accurate API combination recommendations, and improves the overall performance of the mashup. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the embodiment of the present invention and its design scheme, the following briefly introduces the drawings required for this embodiment. The drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0014] Figure 1 A schematic flow chart of an API combination recommendation method provided by an embodiment of the present invention; Figure 2 A schematic diagram of an API relationship diagram provided by an embodiment of the present invention; Figure 3 A schematic diagram of a query graph provided by an embodiment of the present invention; Figure 4 A schematic diagram of a subgraph query provided by an embodiment of the present invention; Figure 5 A comparison chart of the accuracy and recall rates of various recommendation methods provided in an embodiment of the present invention; Figure 6 A comparison chart of the hit rates of various recommendation methods provided in an embodiment of the present invention; Figure 7 A time cost comparison diagram of various recommended methods provided by an embodiment of the present invention; Figure 8 A schematic diagram of the effect of a pruning condition on time cost provided by an embodiment of the present invention; Fig. 9This is the accuracy trend chart of different API graph densities; Fig.10 The recall rate trend chart of different API graph densities; Fig.11 It is the hit rate trend chart of different API graph densities; Fig.12 Time cost trend chart for different API graph densities. DETAILED DESCRIPTION

[0015] In order to enable those skilled in the art to better understand the technical solution of the present invention and implement it, the present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and cannot be used to limit the scope of protection of the present invention.

[0016] In the description of the present invention, it is to be understood that the terms “center”, “longitudinal”, “lateral”, “length”, “width”, “thickness”, “up”, “down”, “front”, “back”, “left”, “right”, “vertical”, “horizontal”, “top”, “bottom”, “inside”, “outside”, “axial”, “radial”, “circumferential”, etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the technical solutions of the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention.

[0017] In addition, the terms "first", "second", etc. are used for descriptive purposes only and are not to be understood as indicating or implying relative importance. In the description of the present invention, it should be noted that, unless otherwise clearly specified or limited, the terms "connected" and "connected" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to the specific circumstances. In the description of the present invention, unless otherwise specified, "plurality" means two or more, which will not be described in detail here.

[0018] First, before introducing the present invention, the problems existing in the prior art are introduced through an example.

[0019] For example, a mashup developer needs to build a travel mashup, which requires the execution of four application tasks: (1) Map service: provides real-time geolocation, navigation, and map functions; (2) Weather service: provides real-time weather information; (3) Social media integration: allows users to share travel experiences, photos, etc.; (4) Language translation service: provides multi-language translation capabilities.

[0020] For travel mashups, there are a series of Web APIs that can meet their needs. For example, APIs that provide map services include Google Maps, Mapbox, etc.; APIs that provide weather services include OpenWeatherMap, WeatherChannel, etc.; APIs that provide social media integration include Facebook Graph, Twitter, etc.; APIs that provide language translation include Google Cloud Translation, Microsoft Translator, etc.

[0021] By flexibly integrating these Web APIs, developers can build a full-featured, user-friendly travel application that meets the diverse needs of users during travel.

[0022] When mashup developers want to query the API sharing repository with four keywords {map, weather, social, language translation} to get the expected API recommendation, they can only get multiple candidate API sets, for example, the API set that provides map functions includes {Google Maps API, Mapbox API,...}; the API set that can query real-time weather conditions includes {OpenWeather API, Weather Channel API,...}; the API set about social media includes {Facebook Graph API, Twitter API,...}; and the API set that implements language translation services includes {Google Translation API, Microsoft Translator API,...}, etc. It can be seen that the traditional keyword-based search method can only provide functionally related API combinations, and does not consider the compatibility between various APIs. If any combination is made in the candidate API set, these APIs may not work together, thus affecting the overall performance of the mashup.

[0023] In view of the above technical problems, the present invention provides an API combination recommendation method, which adopts keyword search technology and subgraph matching technology to recommend API combinations, comprehensively considers functionality and compatibility between APIs, and provides users with accurate and reliable API combination recommendations. Figure 1 As shown, the method comprises the following steps: S1, obtain the function description and historical call records of each API in the mashup, and determine the relationship weight between each API based on the historical call records.

[0024] Among them, the relationship weight is used to characterize the compatibility between APIs.

[0025] Exemplarily, the functional description and historical call records of each API in a mashup can be obtained through an API sharing repository, such as programmableweb.com, which provides basic information about historical call records of 6,146 mashups and 18,478 APIs, including functional descriptions.

[0026] Furthermore, the relationship weights between the APIs are determined based on historical call records. If two APIs appear together n times in a mashup, their relationship weight is 1 / (n+1). This is because when the two APIs have not been called together in a mashup, that is, n=0, the weight will be 1. Such a relationship weight reflects the potential correlation between the two APIs. When the number of times the two APIs appear together in a mashup increases, the edge weight will decrease accordingly, reflecting that the correlation between them is closer. For the specific calculation method, see formula (1). The edge weight reflects the frequency of mutual reference between APIs or simultaneous adoption by developers. The size of the edge weight further reflects the degree of compatibility.

[0027] (1) in, Representation API and API The number of times it is called by the mashup. Representation Node and The edge weights between .

[0028] S2, regards each API as a node, uses the function description as the node label, and uses the relationship weight as the weight of the edge between nodes to build an API relationship graph; obtains the function requirement keywords provided by mashup developers, uses the function requirement keywords as node labels, and builds a query graph.

[0029] First, build an API relationship graph. Specifically, define an adjacency matrix A with a size of , where the elements Indicates API and Second, we construct A based on the history of API calls by mashup. If two APIs have been called by the same mashup, then for ; otherwise it is 0. Then, construct the API relationship graph G=(V,E), take the API node set V as the nodes of the graph, and use the API adjacency matrix A to establish the edge set E to represent the relationship between APIs.

[0030] For each pair If they are called by the same mashup, the value of A[i][j] can be their co-occurrence count. For example, the value of A[i][j] is 3, which means that API and API Occurs 3 times in the same mashup call.

[0031] In the present invention, the API relationship graph is an undirected edge with nodes labeled G=(V,E,Σ,L,EW), where V={v1,v2,......,v n} is the set of API nodes; E={(v i ,v j )|v i ,v j ∈V} represents the set of undirected edges between API nodes; Σ is the set of API node labels; for each node v i ∈V, L(v)∈Σ is v i The label of ; EW represents edge weight.

[0032] It should be understood that in the API relationship diagram, each node represents an independent API, and the label on the node indicates the functional description of the corresponding API.

[0033] If two APIs are called simultaneously by a mashup in the historical call records, there is an undirected edge between the two API nodes. An undirected edge indicates that the two APIs can work together and are compatible with each other.

[0034] Next, combine Figure 2 Explain the API relationship diagram. Figure 2 A schematic diagram of an API relationship diagram provided for an embodiment of the present invention.

[0035] For example, in Figure 2 In the example, the node set V = {v1, v2, v3}, where each node represents an API in the real world. Among them, key1, key2 and key3 are the labels corresponding to nodes v1, v2 and v3 respectively. , and are the corresponding edge weights respectively. The edges between different nodes indicate that different APIs are compatible. For example, the existence of e(v1,v2) indicates that v1 and v2 are compatible with each other.

[0036] When a developer needs to develop a mashup, the functional requirement keywords provided by the mashup developer are obtained, and the functional requirement keywords are used as node labels to build a query graph. Specifically, first, a keyword set is established by extracting the functional requirement keywords of the developer. , where n is the number of keywords. These keywords are related to the specific functions of the requirements. Then, using the keyword set X, a query graph Q=(V*,E*) is constructed, where V* represents the node set and E* represents the edge set. Each keyword in X is mapped to the node label of the query graph one by one, and the relationship between these keywords is expressed through full connection, that is, each keyword Corresponding to a node v in graph Q i .

[0037] Next, combine Figure 3 Explain the query graph. Figure 3 A schematic diagram of a query graph provided by an embodiment of the present invention.

[0038] For example, Figure 3 As shown, there are 5 nodes in the query graph {u1,u2,u3,u4,u5}, and the label corresponding to each node is {k1,k2,k3,k4,k5}. Each label represents a keyword used to describe the function of the API.

[0039] S3, retrieve the subgraph isomorphic to the query graph in the API relationship graph to obtain the candidate subgraph; sum the weights of the edges in each candidate subgraph and calculate the weight score.

[0040] It should be understood that S3 is a subgraph matching process, the purpose of which is to find an API combination that matches the developer's needs in the API relationship graph.

[0041] Next, combine Figure 4 Introduce the process of subgraph matching. Figure 4 A schematic diagram of a subgraph query provided by an embodiment of the present invention, Figure 4 Figure (a) in is the query graph. Figure 4 Figure (b) is the data graph.

[0042] For example, the data graph itself contains multiple node labels, Figure 4 For example, the data graph includes node labels A, B, C, D, and E. Figure 4 As shown in Figure (a) in the figure, given the query graph node set is {u1,u2,u3}, the edge set is {(u1,u2),(u1,u3),(u2,u3)}, and the node label set to be queried is {A,B,C}, when looking for isomorphic subgraphs, it is necessary to consider whether the node labels and edges in the searched graph G match the node labels and edges in the query graph q. During the search, there are two isomorphic subgraphs in the graph G, such as Figure 4 As shown in Figure (b) in the figure, the returned node sets are {v1,v2,v6} and {v1,v5,v6}.

[0043] Subgraph matching is mainly completed through the subgraph matching algorithm. During the execution of the algorithm, the API relationship graph G and the query graph Q are input. The algorithm mainly consists of two stages: filtering stage and verification stage.

[0044] In the filtering phase, for each node in the query graph Q Traverse the API relationship graph G and generate nodes The candidate set C(u) that matches. This candidate set contains The matching nodes, that is, the labels of the nodes in the candidate set are the same as the label of node u'. If the candidate set C(u) is empty, it means there is no matching node and it is returned directly. The algorithm will then verify the candidate matches to find all valid matches.

[0045] After determining the candidate set for each node in the query graph Q, a depth-first search strategy is adopted to find all isomorphic subgraphs of Q in G using the stack as the data structure.

[0046] The specific process is as follows: Initialization phase: First, based on the label of each node in the query graph, find all nodes with the same label in the data graph and build a candidate set for each query graph node. Use a stack (or recursive call stack) to store the current mapping state and the nodes to be processed. Each element in the stack can be a structure containing the current mapping and the remaining unmapped nodes.

[0047] Depth-first search process: Select a starting node: Select an unmapped node from the query graph as the starting node (usually it can be an arbitrary node, or a node selected according to some heuristic strategy).

[0048] Candidate node selection: Select a candidate node from the candidate set of the starting node for mapping.

[0049] Pushing into the stack: Push the current mapping (i.e., the mapping from the starting node to the candidate node) and the remaining unmapped query graph nodes into the stack. At this point, the top element of the stack represents a state of the current search path.

[0050] Iterative search: Pop a state (i.e. the current mapping and the remaining nodes) from the stack.

[0051] If the remaining nodes are empty, it means that all nodes in the query graph have been successfully mapped. At this time, isomorphism verification is performed. The verification process usually involves checking whether the mapped subgraph has the same topological structure and labels as the query graph. This can be achieved through depth-first traversal or breadth-first traversal, while comparing the labels and neighbor structures of the corresponding nodes.

[0052] If the verification passes, an isomorphic subgraph has been found and can be recorded.

[0053] If the verification fails or there are still remaining nodes, an unmapped node is selected and a candidate node is selected from its candidate set for mapping.

[0054] Push the new mapping and the updated remaining nodes onto the stack again.

[0055] Backtrack: If you try to map a node and find that its candidate set is empty (that is, there is no suitable candidate node to map), or if the mapping causes the subsequent nodes to be unable to find a suitable mapping (for example, the neighbor structure does not match), you need to backtrack. Backtracking means popping the current state from the stack, returning to the previous state, and trying the next candidate node in that state.

[0056] When the stack is empty, it means that all possible mappings have been tried and there are no more states to backtrack to, and the search process terminates.

[0057] In the above embodiment, the search state is saved by a stack structure, which avoids the problem of excessive recursion depth, ensures that the algorithm can effectively handle large-scale graph mapping problems, and ultimately obtain all isomorphic subgraphs of graph Q in graph G.

[0058] It should be understood that in the process of subgraph matching, pruning of candidate sets is a key step, which helps to reduce the search space and improve the efficiency of the algorithm. The present invention prunes the candidate set by introducing multiple constraints, including label constraints, neighbor constraints and degree constraints.

[0059] Label constraint: The generation of candidate set C(u) is affected by label constraints. Only nodes in graph G that have the same label as node u' in query graph Q can be included in C(u). In this way, nodes that do not match the query node label are excluded, reducing the possibility of matching.

[0060] Neighbor Constraints: Neighbor connection pruning reduces the search space by ensuring that the neighbors of nodes in the query graph Q have a corresponding relationship with the neighbors of nodes in the graph G. This step is to ensure that the selected candidate nodes have the same neighbor relationship as the nodes in the query graph. In this pruning process, the neighbors of node v are checked by checking the corresponding positions of the adjacency matrix to determine whether the neighbors of node u have a connection relationship with the neighbors of node v.

[0061] Degree constraint: Degree constraint refers to filtering candidate nodes based on the degree of the node (that is, the number of edges connected to the node). In subgraph matching, if a node in the query graph has a specific degree, then the candidate nodes matching the node in graph G should also have the same degree. This constraint can further narrow the search range and improve matching efficiency. The condition of the degree constraint can be expressed by the following mathematical expression: degree(u')>=degree(v').

[0062] Among them, degree(u') represents the degree of node u' in the query graph Q, and degree(v') represents the degree of the corresponding candidate node v' in the graph G. This condition ensures that only those candidate nodes v' whose degree is not less than the degree of the query node u' can be retained as candidate nodes.

[0063] The present invention screens the entire graph G, retaining only the node set and edge set related to the node labels of the graph Q, and removing the nodes and edges that are not related to the graph Q. Thus, a more accurate and targeted result is obtained. This screening method helps to improve the accuracy and efficiency of the query.

[0064] Furthermore, after obtaining the candidate subgraphs through subgraph matching, the edge weights in each candidate subgraph are directly added to calculate the weight score.

[0065] S4, sort the subgraphs based on the weight scores, and select the API combinations in the top k subgraphs as the target combinations for recommendation.

[0066] For example, if there are 5 candidate subgraphs, the candidate subgraphs can be sorted in ascending order according to the weight scores, and the API combinations in the top k (for example, 3) subgraphs are selected as the final recommendation results. These recommendation results will be presented to developers in a clear manner to help them choose the most appropriate API combination in their projects, thereby improving development efficiency and result quality.

[0067] Next, the effectiveness and practicability of the present invention are verified through experiments.

[0068] First, prepare the dataset.

[0069] The dataset used in the experiment was crawled from programmableweb.com, an online API sharing repository. Based on this information, an API relationship graph G is established. Since the PW platform uses keywords to describe the functions of Web APIs, we use these keywords as labels for the nodes in the API relationship graph G. In graph G, if any of the 6146 mashups directly calls several Web APIs, the nodes they represent will be connected. In order to ensure the effectiveness of the experiment, the dataset was grouped according to the number of keywords. During the experiment, experiments were conducted for different numbers of keywords, and the functional keywords expected by mashup developers were randomly generated to verify the reliability and consistency of the results.

[0070] In order to evaluate the recommended method for the API combination of the present invention (hereinafter referred to as SUBMC WACR ) using multiple evaluation metrics, including Precision, Recall, F1 value, Hit Rate, and Cost Time. These metrics help to fully understand the quality of the recommendation results and the efficiency of the method.

[0071] Precision: used to measure the accuracy of Web API recommendation results.

[0072] Recall: It is used to measure the coverage of the correctly recommended Web APIs in the Web API recommendation results in actual needs.

[0073] Hit Rate: Indicates whether the recommendation list contains the Web APIs that users actually need.

[0074] Cost Time: Indicates the running time of the recommended method. Each set of experiments is repeated 30 times (each) and the average is taken. It is in seconds.

[0075] These evaluation indicators together constitute a comprehensive evaluation of the performance of the present invention, which can provide a more comprehensive understanding of the performance of the method under different numbers of keywords.

[0076] In this paper, we focus on the compatibility-aware Web API recommendation method based on keyword search. WACRIn terms of the effects on improving compatibility and popularity, two leading methods, Web API Recommendation with Weighted Association Rules (WAR) and K-means Clustering based API Recommendation (K-CAR), were selected and compared in detail with two recognized benchmark methods, Greedy and Random.

[0077] In order to more comprehensively consider the possibilities of different combinations, the recommendation results are expanded from the top-ranked API combination to the top-K API combinations. At the same time, the Web API categories included in the mashup are taken as input. The number of final recommended API combinations is set to K={5,10,15}. After 50 experiments, the average values ​​of the evaluation indicators of the five methods are compared, and the results are as follows.

[0078] Precision and recall analysis: The experiments measured the precision and recall of various methods, such as Figure 5 As shown, Figure 5 Figure (a) is a comparison of the accuracy of each recommendation algorithm. Figure 5 Figure (b) in the figure is a comparison of the recall rates of various recommendation algorithms. Figure 5 It can be seen that SUBMC WACR The accuracy of is significantly better than that of WAR, K-CAR, Random, and Greedy. The accuracy of each method increases with the increase of the number of input keywords (i.e., I). The reason can be explained as follows: when there are fewer input keywords (i.e., I is smaller), there are many functionally qualified and compatible Web API combination solutions as candidates; in this case, the possibility that the actual Web API that actually constitutes the APP happens to be the recommended Web API is smaller. Therefore, when I is smaller, the recommendation accuracy is lower. On the contrary, when there are more input keywords (i.e., I is larger), there are fewer functionally qualified and compatible Web API combination solutions as candidates; in this case, the actual API that actually constitutes the APP happens to be the recommended API as a candidate. Therefore, when I becomes larger, the recommendation accuracy is higher.

[0079] Hit rate analysis: The hit rates of various methods were measured, e.g. Figure 6 As shown, SUBMC WACR The hit rate is always higher than K-CAR, WAR, Random and Greedy. Figure 6It intuitively shows the comparison of hit rates under different numbers of keywords when K=5, clearly showing the SUBMC WACR The significant advantages of SUBMC WACR It is used to search for compatible solutions that meet the functional requirements of developers and ultimately recommend the most suitable combination of Web APIs. WACR The returned API is very close to the actual requirement, so SUBMC WACR It is more likely to effectively collect relevant APIs that match developer needs, resulting in a consistently high hit rate. This emphasizes the importance of SUBMC WACR Effectiveness in providing solutions that align with developer needs.

[0080] Time cost analysis: In a short period of time, SUBMC WACR Able to quickly return feasible solutions, continuously improve and provide more compatible functional solutions. The average time to find the best solution is used as SUBMC WACR The time metric of , and compare it with other methods, such as Figure 7 As shown in the experimental results, when the number of input keywords changes from 3 to 7, SUBMC WACR The time cost of SUBMC is always less than that of K-CAR and PC-WAR. This is because WACR By accurately screening the API relationship graph G, irrelevant elements are eliminated. This targeted screening improves the accuracy and efficiency of the query and provides a more compatible and functional solution.

[0081] Pruning condition ablation analysis: The embodiment of the present invention analyzes SUBMC WACR The impact of the three pruning conditions on the cost time, such as Figure 8 As shown, it can be seen that initially, removing the degree constraint leads to a slight increase in time, and the time increases after removing the neighbor constraint. The label and neighbor constraints become the main factors affecting the processing time, and the degree constraint has a smaller impact.

[0082] Analysis of API relationship diagrams of different densities: The embodiment of the present invention studies the impact of different densities of API relationship graphs on performance. The PW dataset is divided into different proportions, where 1-ρ is used to construct the API relationship graph, and the remaining ρ is used as test data to evaluate the algorithm performance (where ρ {1%, 5%, 10%, 20%}). Repeat each experiment multiple times to verify the reliability of the results, and calculate the accuracy, recall, hit rate and cost time of different API graph densities, such as Figures 9 to 12As shown, SUBMC under different data set partitioning strategies is shown. WACR Performance trends, Fig. 9 This is the accuracy trend chart of different API graph densities; Fig.10 The recall rate trend chart of different API graph densities; Fig.11 It is the hit rate trend chart of different API graph densities; Fig.12 The time cost trend chart for different API graph densities. After 50 repeated experiments, it was found that various indicators finally stabilized under each different ρ value, highlighting SUBMC WACR The excellent performance in terms of convergence further verifies the rationality of the method of repeating the experiment and taking the average value.

[0083] In summary, the present invention has obvious advantages over other methods in terms of recommendation accuracy and performance.

[0084] Based on the same inventive concept, an embodiment of the present invention further provides an API combination recommendation device, which includes: The acquisition module is used to obtain the function description and historical call records of each API in the mashup, and determine the relationship weights between each API based on the historical call records. The relationship weights are used to characterize the compatibility between APIs.

[0085] The building module is used to construct an API relationship graph by treating each API as a node, using the function description as the node label, and the relationship weight as the weight of the edge between nodes; obtaining the function requirement keywords provided by the mashup developers, using the function requirement keywords as the node labels, and constructing a query graph.

[0086] The search module is used to retrieve subgraphs isomorphic to the query graph in the API relationship graph to obtain candidate subgraphs; the weights of the edges in each candidate subgraph are summed up to calculate the weight score.

[0087] The recommendation module is used to sort the subgraphs based on the weight scores and select the API combinations in the top k subgraphs as the target combinations for recommendation.

[0088] Each module in the above-mentioned API combination recommendation device can be implemented in whole or in part by software, hardware and their combination. Each module can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module above.

[0089] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps in the API combination recommendation method embodiment. The specific implementation method can be found in the method embodiment, which will not be repeated here.

[0090] Furthermore, the present invention also provides a non-temporary computer-readable storage medium containing instructions, and a computer program is stored on the storage medium. For example, a memory containing instructions, the above instructions can be executed by a processor of a computer device to complete the above method. For example, a non-temporary computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device. When the computer program is executed by the processor, the steps in the API combination recommendation method embodiment can be implemented. The specific implementation method can be found in the method embodiment, which will not be repeated here.

[0091] It should be understood by those skilled in the art that embodiments of the present invention may provide methods, systems or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0092] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as a combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0093] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0094] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0095] It should be pointed out that the specific implementation methods described above can enable those skilled in the art to understand the invention more comprehensively, but do not limit the invention in any way. Therefore, although the invention has been described in detail in this specification and embodiments, those skilled in the art should understand that the invention can still be modified or replaced by equivalents; and all technical solutions and improvements that do not deviate from the spirit and scope of the invention are included in the protection scope of the invention. Any figure mark in the claims should not be regarded as limiting the claims involved. Any simple change or equivalent replacement of the technical solution that can be obviously obtained by any technician familiar with the field within the technical scope disclosed in the present invention belongs to the protection scope of the present invention.

Claims

1. A method for recommending an API combination, characterized in that: include: Obtain the function description and historical call records of each API in the mashup, and determine the relationship weights between each API based on the historical call records. The relationship weights are used to characterize the compatibility between APIs. Consider each API as a node, use the function description as the node label, and use the relationship weight as the weight of the edge between nodes to build an API relationship graph; obtain the function requirement keywords provided by mashup developers, use the function requirement keywords as node labels, and build a query graph; Retrieve the subgraphs that are isomorphic to the query graph in the API relationship graph to obtain candidate subgraphs; sum the weights of the edges in each candidate subgraph to calculate the weight score; Sort the subgraphs based on the weight scores and select the top ranked The API combination in the sub-graph is recommended as the target combination. is an integer greater than or equal to 1.

2. The API combination recommendation method according to claim 1, characterized in that: Determine the relationship weights between APIs based on historical call records, including: Determine the number of times any two APIs are called together by the same mashup based on historical call records; The relationship weights between APIs are determined based on the number of common calls. The formula for calculating the relationship weights is: ； in, Representation API and API The number of times it is called by the mashup. Representation Node and The edge weights between The smaller the API and API The better the compatibility.

3. The API combination recommendation method according to claim 1 or 2, characterized in that: The subgraph matching algorithm is used to retrieve the subgraphs that are isomorphic to the query graph in the API relationship graph, and the candidate subgraphs are obtained, including: Traverse the API relationship graph for each node u' in the query graph and generate a candidate set that matches the node u'. The labels of the nodes in the candidate set are the same as the label of the node u'. Select an unmapped node in the query graph as the starting node, select a candidate node from the candidate set of the starting node for mapping; push the current mapping and the remaining unmapped nodes in the query graph into a stack; If the remaining unmapped nodes in the stack are empty, perform isomorphism verification to check whether the mapped subgraph has the same topological structure and label as the query graph; the subgraph that passes the verification is used as a candidate subgraph; If the verification fails or there are still unmapped nodes, an unmapped node is selected and a candidate node is selected from the corresponding candidate set for mapping. The new mapping and the updated remaining nodes are pushed into the stack again until the stack is empty.

4. The API combination recommendation method according to claim 3, characterized in that: After traversing each node u' in the query graph in the API relationship graph and generating a candidate set matching the node u', the following steps are also included: The candidate set is pruned by label constraints, neighbor constraints, and degree constraints.

5. An API combination recommendation device, characterized in that: include: The acquisition module is used to obtain the function description and historical call records of each API in the mashup, and determine the relationship weights between each API based on the historical call records. The relationship weights are used to characterize the compatibility between APIs. A construction module is used to construct an API relationship graph by treating each API as a node, using the function description as the node label, and using the relationship weight as the weight of the edge between nodes; obtaining the function requirement keywords provided by mashup developers, using the function requirement keywords as node labels, and constructing a query graph; A search module is used to retrieve a subgraph isomorphic to the query graph in the API relationship graph to obtain a candidate subgraph; the weights of the edges in each candidate subgraph are summed to calculate a weight score; The recommendation module is used to sort the subgraphs based on the weight scores and select the API combinations in the top k subgraphs as the target combinations for recommendation.

6. A computer device, characterized in that: The invention comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for recommending an API combination according to any one of claims 1 to 4 is implemented.

7. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the API combination recommendation method according to any one of claims 1 to 4 is implemented.

Images