Recommending third-party APIs via using lightweight graph convolutional neural networks

Abstract

Third-party APIs have been widely used to develop various applications. As the number of third-party APIs grows, it becomes increasingly challenging to quickly find suitable APIs that meet users’ requirements. Inspired by recommender systems, API recommendation methods have been proposed to address this issue. However, previous API recommendation methods are insufficient in utilising the high-order interactions between users and APIs, and thus have limited performance. Based on the model of lightweight graph convolutional neural network, this paper proposes an effective API recommendation method by exploiting both low-order and high-order interactions between users and APIs. It first learns the embedding of users and APIs from the user-API interaction graph, and then adopts a weighted summation operator to aggregate the embeddings learned from different propagation layers for API recommendation. Extensive experiments are conducted on a real dataset with 160,309 API users and 21,031 Web APIs, and the results show that our method has significantly better precision and recall than other state-of-the-art methods.

KEYWORDS:

• Third-party APIs
• API recommendation
• graph convolution networks
• collaborative filtering

1. Introduction

Driven by the API (Application Programming Interface) economy (Liu et al., 2007; Yu et al., 2021; Xu et al., 2023), more and more companies have provided open APIs to allow the public accessing their services or data in a programmable way. Those APIs are usually referred to as third-party APIs. As the number of third-party APIs grows, reusing them to develop new applications has received great interests from developers (Chen et al., 2021; Tang et al., 2019b; Tang et al., 2019c). Against this background, several popular third-party API portals and search engines arise, such as ProgrammableWeb (ProgrammableWeb.com) and Baidu API store (apis.baidu.com).

Although the massive APIs make it more convenient for developers (users) to develop applications quickly, they also arouse a serious information overload problem when looking for suitable APIs. According the latest statistics, there are more than 24,000 APIs in ProgrammableWeb, and the number is still growing rapidly. Although ProgrammableWeb has provided keyword-based search functions for API users, it is still a time-consuming task for users to quickly find an API that meets their needs. Inspired by success of recommender systems, API recommendation has been adopted to address the above issue (Lian & Tang, 2022). Through API recommendation, it can not only alleviate the information overload issue in the API discovery process, but also can promote the reuse of APIs by recommending new APIs, thereby advancing the development of the entire API ecosystem (Guo et al., 2022).

In order to effectively recommend useful APIs to users, a lot of research work has been done. Existing API recommendation methods can be roughly divided into content-based (Li et al., 2013; Shi et al., 2019; Qi et al., 2021), QoS (quality of service)-based (Wu et al., 2018; Luo et al., 2020; Tang et al., 2019a; Zheng et al., 2022) and Mashup-oriented (Li et al., 2017; Wang et al., 2018; Xue et al., 2017). Most of the methods rely on the historical interaction records of users and API services and employ collaborative filtering (CF) to recommend useful APIs. However, in real API recommendation scenarios, the number of APIs that a user has used is usually small, and thus the interaction data between users and APIs are likely very sparse. Consequently, accurate API recommendation becomes a challenging problem.

Recently, the application of deep learning and graph neural networks (GNN) in recommendation systems has gained much attention (Liang et al., 2022b; Liang et al., 2022c; Zou et al., 2021). By deeply exploring the interaction information between users and items to obtain better representations of users and items, GNN has shown effectiveness in many recommender systems (Song et al., 2022; Liang et al., 2022a). In API recommendations, data can be modelled in the form of graph structure, and GNN is typically good at capturing the links between users and APIs. Therefore, it is natural to apply GNN to API recommendations. Among all GNN algorithms, Graph Convolutional Neural Network (GCN) (Kipf & Welling, 2016) is the most successful one. However, GCN was originally proposed to classify nodes on graphs where nodes have rich attributes and features. When only the user-API interaction matrix is considered, the features of each user and API can be represented by a simplified one-hot vector, which indicates that straightforwardly applying the classic GCN to API recommendation may result in an unsatisfactory trade-off between performance and complexity of the model (He et al., 2020). To overcome such weakness, He et al. (2020) proposed a lightweight graph convolutional neural network named LightGCN, which simplified the message construction and aggregation of the classic GCN.

This paper extends the application of GCN to third-party API recommendations. Based on the interactions between users and APIs, this paper proposes an efficient API recommendation method via adapting LightGCN. That is, we focus on simplifying neighbour aggregation, the core function of GCN, so that we can simplify the train process of the model while retaining high recommendation performance. The contributions of this paper are summarised as follows:

• We proposed an efficient API recommendation method based on the interactions between users and APIs, which adopts a lightweight GCN model to simplify the train process of the classic GCN and improve its performance.

• We built a large-scale real API usage dataset from ProgrammableWeb.com, which contains 160,309 API users, 21,031 Web APIs, and 306,751 interactions between them.

• We conducted a series of experiments to evaluate the proposed API recommendation method on real data, and compared it with several state-of-the-art recommendation methods. The results demonstrate that our proposed method outperforms the baselines significantly.

The rest of this paper is organised as follows: Section 2 surveys related work on API recommendation. Section 3 presents the motivation of this work. Section 4 describes our proposed method, which is based on a lightweight GCN model. Section 5 presents the experimental evaluation of the proposed method. Finally, Section 6 concludes the paper and outlines future research.

2. Related work

Existing API (or web service) recommendations can be roughly categorised into three categories: content-based methods, QoS-based methods and Mashup-oriented methods. This section surveys them as follows.

Content-based API recommendation methods primarily focus on exploiting the properties of APIs such as their functionality description, and find the appropriate APIs by calculating their description’ s semantic similarity with the users’ requirements. Li et al. (2013) used a probabilistic topic model to address the API recommendation problem. They firstly obtain the topic vectors of the API’s description and user’s requirements, and then calculate the matching degree of the two topic vectors to complete the recommendation task. Shi et al. (2019) expanded the services’ description at sentence level based on a novel probabilistic topic model and use a Long Short-Term Memory(LSTM)-based model to recommend services with two attention mechanisms.

QoS-based methods recommend APIs by predicting the missing QoS values. Tang et al. (2016) and Liu et al. (2016) revamped memory-based CF by integrating the location information of users and services to make QoS predictions. To overcome the weakness of memory-based CF raised by data sparsity, model-based CF methods such as Matrix Factorization (MF) or Factorization Machine (FM) have also been applied to QoS predictions (Tang et al., 2021; Xu et al., 2021). For a comprehensive survey of the state-of-the-art QoS prediction methods, please refer to the literature (Zheng et al., 2022).

API recommendation for Mashup creation has also gained much attention recently. Related work in this direction primarily exploited the invocation relationships between APIs and Mashup applications (Tang et al., 2019a). Li et al. (2017) proposed an API recommendation method for Mashups by integrating tags, topics, co-occurrence relationships and popularity of APIs. Wang et al. (2018) established a knowledge graph of APIs and recommended APIs through random walks on the knowledge graph. Xue et al. (2017) used word embedding to measure the similarity of APIs, and then identified a set of APIs for recommendation by leveraging API clusters and sub-clusters.

Different from the afore-mentioned work, the work in this paper recommends APIs to users (or developers), instead of Mashup applications. Therefore, we exploit the interaction information between users and APIs, instead of between Mashups and APIs.

3. Motivating example

Figure 1 is an example illustrating the motivation of this work. The left part of Figure 1 is a user-API interaction graph. The link between a user u and an API i indicates that the user has interacted with the API before. The right part is a tree structure originating from $u_1$ that reflects its low-order and high-order connections. For example, $u_1$ and $i_1$ have a first-order connection because they are directly connected in the user-API interaction graph, i.e. they had direct interactions in the past. Traditional CF-based API recommendation methods usually employ only the low-order connections to identify neighbours by calculating their similarities, and based on which to make API recommendations. For example, $u_1$ and $u_2$ are both directly connected with $i_2$, thus can be considered as similar neighbours. As a result, the APIs used by u₁ can also be recommended to $u_2$, such as $i_1$ and $i_2$.

Figure 1. A motivating example.

Traditional CF-based API recommendation methods often ignore the higher-order connections between users and APIs, which, however, have rich semantic information. Let’s further use Figure 1 as an example to explain how to exploit the high-order connection information. There is a four-hop (i.e. four-order) connection between users $u_4$ and $u_1$, i.e. $u_4\to i_4\to u_2\to i_2\to u_1$. Since $u_4$ share similar preference with $u_2$, and $u_2$ share similar preference with $u_1$. To some extent, $u_4$ and $u_1$ are also similar. Thus, such similarity relationships should also be taken into account in API recommendations. Since GCNs have been proved to be very efficient in exploring the high-order interactions between users and items when applied to recommender systems, this work utilises the GCN model to aggregate both low-order and high-order interaction information between users and APIs for API recommendations.

4. Proposed method

In this paper, we propose an efficient API recommendation method based on LightGCN, which is a lightweight GCN model (He et al., 2020). The method mainly consists of three stages: (1) Initial embedding: this procedure initialises the embedding of APIs and users; (2) Embedding propagation: this procedure performs the multi-layer embedding propagation on the graph to refine the embeddings of APIs and users for better representations; (3) Embeddding aggregation and API prediction: this procedure aggregates all embeddings from different layers to calculate users’ preference scores for different APIs, which are finally used for API ranking and recommendation.

4.1 Initial embedding

In this stage, following NCF (Wang et al., 2019), each user and API is first associated with an ID embedding, which is based on one-hot encoding. Then the sparse vector of each user and API is transformed to a dense vector through a fully connected layer. Consequently, we obtain initial representations for each user and API. Let $e_u^0\in {\mathbb{R}}^d$ represent the initial embedding of a user u and $e_i^0\in {\mathbb{R}}^d$ represent the initial embedding of an API i, where $d$ is the size of embedding dimension. The user (API) matrix can be formed by combining all user (API) vectors, as follows: (1) $\begin{array}{rl}{E}_u& =\left[e_{u1}^0,e_{u2}^0,\dots ,e_{uM}^0\right]\end{array}$(1) (2) $\begin{array}{rl}{E}_i& =\left[e_{i1}^0,e_{i2}^0,\dots ,e_{iN}^0\right]\end{array}$(2) where M is the number of users and N is the number of APIs. The above matrix only represents the initialisation state of all users or APIs. We employ a multi-layer embedding propagation on the users-API interaction graph to optimise the representations of users and APIs.

4.2 Embedding propagation

Following (Hamilton et al., 2017; Xu et al., 2018), we design a lightweight messaging architecture to capture their collaborative filtering signals on the interaction graph which is built from the interactions between users and APIs, and then optimise the embedding of users and APIs. We first describe the first-layer embedding propagation, and then extend it to multi-layer propagation.

4.2.1 First layer propagation

We propagate users and APIs embeddings on the graph using two operations: message construction and message aggregation.

Message Construction. For a user and API pair $\left(u,i\right)$, we can define a message from the API to the user as: (3) ${\mathbf{\text{m}}}_{u\leftarrow i}=f\left({\mathbf{\text{e}}}_i,p_{ui}\right)$(3) where ${\text{m}}_{\text{u}\leftarrow \text{i}}$ is the representation of the message from API $i$ to user $u$, $f(\cdot )$is a message encoding function, which takes the embedding of the API as an input, and uses the coefficient $p_{ui}$ to control the decaying factor of each propagation on the edge $\left(u,i\right)$. From the perspective of representation learning, $p_{ui}$ reflects how much API i contributing to the preference learning of user u. Like the classic GCN, we set $p_{ui}$ as the graph Laplacian norm $1/\sqrt{|{\mathcal{N}}_{\text{u}}||{\mathcal{N}}_{\text{i}}|}$, where ${\mathcal{N}}_{\text{u}}$ and ${\mathcal{N}}_{\text{i}}$ respectively represent the first-hop neighbours of user $u$ and API $i$. In this model, we implement $\text{f}(\cdot )$ as follows: (4) ${\mathbf{\text{m}}}_{u\leftarrow i}=\frac{1}{\sqrt{|{\mathcal{N}}_u||{\mathcal{N}}_i|}}{\mathbf{\text{e}}}_i$(4) Message Aggregation. In this step, we use an aggregation function to aggregate the messages propagated by the neighbours of user $u$ to optimise the embedding representation of $u$. For simplicity, we use a simple weighted sum aggregator instead of feature transformations and nonlinear activation functions. It is worth mentioning that, unlike other graph neural networks, we do not integrate the target node itself (i.e. self-connection). Since the combination operation (will be discussed later in the next section) achieves a similar effect to self-connection, self-connection is not a necessity here. Specifically, our aggregate function can be defined as: (5) ${\mathbf{\text{e}}}_u^1=\sum _{i\in {\mathcal{N}}_u}{\mathbf{\text{m}}}_{u\leftarrow i}$(5) where $e_u^1$ represents the representation of user $u$ after the first embedding propagation, ${\mathcal{N}}_{\text{u}}$ represents the one-hop neighbours of user $u$. Similarly, we can obtain the representation of API $i$, $e_i^1$, by propagating the information of users connecting API $i$: (6) ${\mathbf{\text{e}}}_i^1=\sum _{u\in {\mathcal{N}}_i}{\mathbf{\text{m}}}_{i\leftarrow u}$(6) where $e_i^1$ represents the representation of API $i$ after the first embedding propagation, ${\mathcal{N}}_i$ represents the one-hop neighbours of API $i$.

4.2.2 Multi-layer propagation

The refined representation can be obtained after the first-layer graph propagation. Then, we can stack multiple embedding propagation layers to explore the higher-order connectivity information. By stacking $k$ layers to embedding propagation layer, users and APIs can receive messages propagated from their $\text{k}$-hop neighbours, the representation of user $u$ in the $\text{k}$-th layer can be calculated as: (7) ${\mathbf{\text{e}}}_u^{k+1}=\sum _{i\in {\mathcal{N}}_u}\frac{1}{\sqrt{|{\mathcal{N}}_u|}\sqrt{|{\mathcal{N}}_i|}}{\mathbf{\text{e}}}_i^k$(7)

4.3 Embedding aggregation and API prediction

In this method, the embedding at layer 0 (i.e. the initial user and API embedding representation), $e_u^0$ of all users and $e_i^0$ of all APIs are the only model parameters that can be trained. Using the embeddings of users and APIs at layer 0, after the $\text{k}$-layer graph propagation operation, we can aggregate the embeddings from different propagation layers and obtain the final embeddings of users and APIs: (8) $\begin{array}{rl}{\mathbf{\text{e}}}_u& =\sum _{k=0}^K{\alpha }_k{\mathbf{\text{e}}}_u^k\end{array}$(8) (9) $\begin{array}{rl}{\mathbf{\text{e}}}_i& =\sum _{k=0}^K{\alpha }_k{\mathbf{\text{e}}}_i^k\end{array}$(9) where, ${\alpha }_k\ge 0$ indicates the importance of the $k$-th embedding in the final embedding. In order to make our model easier to train, we simply set ${\alpha }_k$ to $1/\left(k+1\right)$ here. Unlike other graph neural networks, we do not integrate the target node itself (i.e. self-connection). We aggregate embeddings from different propagation layers to achieve the effect of self-connection (Wu et al., 2019). As the number of layers increases, the embeddings of users and APIs will become more smooth (Li et al., 2018). Secondly, the embeddings from different layers capture different semantics, for example, higher layers will capture higher levels of proximity (Wang et al., 2019), so it’s beneficial to aggregate embeddings from multiple propagation layers.

We use the inner product of the final representations of user u and API i to calculate the user’s preference score for the target API: (10) ${\hat{y}}_{ui}={\mathbf{\text{e}}}_u^T{\mathbf{\text{e}}}_i$(10) where ${\mathbf{\text{e}}}_u$ and ${\mathbf{\text{e}}}_i$ are the final embedding representations of user u and API i respectively. Meanwhile, we use the Bayesian Personalized Ranking (BPR) as the loss function (Rendle et al., 2009). BPR loss is a pairwise loss function and has been widely used in recommender systems. It assumes that the predicted scores of positive samples (positive samples indicate that there exists an interaction relationship between the user and the item) should be higher than negative samples. The loss function is thus defined as follows: (11) $L_{BPR}=-\sum _{u=1}^M\sum _{i\in {\mathcal{N}}_u}\sum _{j\notin {\mathcal{N}}_u}\ln \sigma ({\hat{y}}_{ui}-{\hat{y}}_{uj})+\lambda {\mathbf{\text{E}}}^{\left(0\right)2}$(11) where ${\mathbf{\text{E}}}^{\left(0\right)}$ represents the embeddings of the 0-th layer, $\sigma (\cdot )$is the sigmoid function, and λ controls the strength of $L_2$ regularisation.

4.4 Matrix form

In order to further illustrate the embedding propagation and facilitate implementation, we also provide a matrix form of the proposed method. Let the user-API interaction matrix be $\text{R}\in {\mathbb{R}}^{\text{M}\times \text{N}}$, where M and $N$ represent the number of users and APIs, respectively. In the matrix, if a user $u$ has interacted with an API $i$, the value of $R_{ui}$ is set as 1, otherwise it is set as 0. The adjacency matrix of the user-API graph can be defined as follows: (12) $\mathbf{\text{A}}=\left(\begin{array}{cc}0& \mathbf{\text{R}}\\ {\mathbf{\text{R}}}^T& 0\end{array}\right)$(12) where $T$ is the embedding size. The 0-th layer embedding matrix is ${\mathbf{\text{E}}}^0\in {\mathbb{R}}^{\left(M+N\right)\times T}$. Then we have the matrix equivalent form of equation (7)(13) $\begin{array}{c}{\mathbf{\text{E}}}^{k+1}=\left({\mathbf{\text{D}}}^{-\frac{1}{2}}\mathbf{\text{A}}{\mathbf{\text{D}}}^{-\frac{1}{2}}\right){\mathbf{\text{E}}}^k\end{array}$(13) as: (13) $\begin{array}{c}{\mathbf{\text{E}}}^{k+1}=\left({\mathbf{\text{D}}}^{-\frac{1}{2}}\mathbf{\text{A}}{\mathbf{\text{D}}}^{-\frac{1}{2}}\right){\mathbf{\text{E}}}^k\end{array}$(13) where D is a (M + N) × (M + N) diagonal matrix, and each entry ${\text{D}}_{\text{ww}}$ in D denotes the number of nonzero entries in the w-th row vector of the adjacency matrix A (also called degree matrix). Finally, we can obtain the final embedding matrix used for prediction as below: (14) $\begin{array}{rl}E& ={\alpha }_0{\mathbf{\text{E}}}^0+{\alpha }_1{\mathbf{\text{E}}}^1+{\alpha }_2{\mathbf{\text{E}}}^2+\dots +{\alpha }_K{\mathbf{\text{E}}}^k\\ & ={\alpha }_0{\mathbf{\text{E}}}^0+{\alpha }_1\widetilde{\mathbf{\text{A}}}{\mathbf{\text{E}}}^0+{\alpha }_2{\widetilde{\mathbf{\text{A}}}}^2{\mathbf{\text{E}}}^0+\dots +{\alpha }_k{\widetilde{\mathbf{\text{A}}}}^k{\mathbf{\text{E}}}^0\end{array}$(14) where ${\alpha }_{\text{k}}$ represents the weight of the $\text{k}$-th layer embedding during the final embedding generation and $\tilde{\mathrm{A}}={\text{D}}^{-\frac{1}{2}}\text{A}{\text{D}}^{-\frac{1}{2}}$ is the symmetrically normalised matrix.

5. Experiments

5.1 Dataset description

The dataset used in the experiments comes from the popular third-party API portal and search engine Programmableweb.com. The original dataset we crawled from Programmableweb contains 21,031 APIs, 160,309 users and 306,751 interactions between users and APIs (i.e. users following APIs). Since most users only follow a small number of APIs, for the sake of evaluation we remove the users that follow less than five APIs as well as corresponding APIs. As a result, the dataset after preprocessing has 6,684 APIs, 21,031 users and 121,670 user-API interactions. The statistics of the dataset is shown in Table 1. We further randomly divide the datset into a training set and a test set with a ratio of 8:2.

Table 1. Statistics of the dataset.

	User	API	Interactions	Density
Original	160309	21031	306751	0.00009
After Processing	6684	21031	121670	0.00087

5.2 Evaluation metrics

In order to verify the performance of our proposed API recommendation method, we choose Recall@K (Recall at K) and NDCG@K (Normalized Discounted Cumulative Gain at K) as our evaluation metrics, which are widely used in recommendation method evaluation (Yang et al., 2018). More specifically, Recall@K is used to measure the proportion of retrieved APIs among all relevant APIs; NDCG@K (N@K) is used to measure the relevance of retrieved APIs, which takes into account the position of APIs in the Top-K recommendation list. In our experiments, we set K as 5, 10, 15, 20, respectively.

5.3 Baseline methods

To conduct comparison experiments, we use the following methods as baselines:

• BPRMF (Rendle et al., 2009): It is a matrix factorisation method optimised by the Bayesian personalized ranking (BPR) loss, which exploits only the direct interactions between users and APIs as the target value of interaction function.

• NMF (He et al., 2017): It uses an advanced neural CF model based on GMF and MLP to learn independent embedding of users and APIs and concatenate them to capture their nonlinear feature interactions.

• GC-MC (Berg et al., 2017): It can be regarded as a link prediction method on the graph. The interactions between users and APIs are represented as a bipartite graph. GC-MC adopts a GCN encoder to generate the representations of users and APIs, and only the one-hop neighbours are considered. By propagating the information on the bipartite graph, the latent features of users and APIs can be obtained.

• NGCF (Wang et al., 2019): It uses the bipartite neural network to encode historical interaction information between users and APIs into the embedding representations of users and APIs. Moreover, it explicitly considers the high-order connectivity between users and APIs to further enhance the representation ability of embedding.

The hyperparameters of the baseline methods are set as suggested in their paper. For fair comparison, all the baseline methods are optimised using the BPR loss.

5.4 Experimental results

In this section, we compare the proposed method to all the baseline methods in terms of recommendation performance. The experimental results are shown in Tables 2 and 3, Figures 2 and 3. They are explained as follows:

• In all cases, the proposed method has the best performance. It improves Recall@20 by 46.79%, 35.92%, 37.01%, and 28.68% compared with BPRMF, NMF, GC-MC and NGCF, respectively. And NDCG@20 is improved by 50.22%, 23.39%, 25.07% and 9.68%, respectively. Due to its simple structure, this method is also easier to train.

• BPRMF loss has the poorest performance among all comparison methods. It shows that inner product is not enough to reflect the deep interactions between users and APIs, which limits the performance of the model. GC-MC has better performance than BPRMF, indicating that the introduction of first-order neighbours does improve the representation of users and APIs. In most cases, NMF performs better than GC-MC, indicating the importance of non-linear feature interactions between user and API. However, none of them explicitly encode the connections between users and APIs in the embedding learning, thus resulting in suboptimal representations.

• NGCF explicitly encodes the historical interaction information between users and APIs into the embedding. With a better embedding representation, it achieves the best performance among all baseline methods.

Figure 2. Comparisons of Recall@K.

Figure 3. Comparisons of NDCG@K.

Table 2. Comparisons of Recall@K.

	5	10	15	20
BPRMF	0.0704	0.0978	0.1280	0.1513
NMF	0.0874	0.1170	0.1460	0.1634
GC-MC	0.0842	0.1120	0.1388	0.1621
NGCF	0.0948	0.1259	0.1561	0.1726
Proposed Method	0.1099	0.1590	0.1933	0.2221

Table 3. Comparisons of NDCG@K.

	5	10	15	20
BPRMF	0.0552	0.0715	0.0821	0.0920
NMF	0.0685	0.0880	0.1018	0.1120
GC-MC	0.0674	0.0915	0.1050	0.1105
NGCF	0.0793	0.1030	0.1182	0.1260
Proposed Method	0.0974	0.1175	0.1292	0.1382

5.5 Hyperparameter analysis

In this section, we discuss the impact of the method’s hyperparameters on the recommendation performance. The hyperparameters to be evaluated include the embedding size of users and APIs, and the L2 regularisation coefficient λ. When a parameter is evaluated, the remaining parameters are fixed.

Figure 4 shows that increasing the embedding size of users and APIs can effectively improve the performance of the method. When the regularisation coefficient λ is set to 1e-4, with the embedding size rising from 8 to 64, Recall@20 increases 44% from 0.1544 to 0.2221. At the same time, NDCG@20 also increases by 48% to 0.1382. When the embedding size increases to more than 64, the growth rate drops significantly, and the training time begins to increase significantly. Therefore, we argue that the embedding size of 64 is a better choice. If the embedding size is too small, it may result in user or API information missing in the embedding. On the contrary, if the embedding size is too large, it will cause information redundancy and increase the training time.

Figure 4. Impact of the embedding size.

In addition to the embedding size, the L2 regularisation coefficient λ is also evaluated in the experiments. Regularisation is a commonly used technique in machine learning. Its main purpose is to control the complexity of the model and avoid overfitting. As shown in Figure 5, when the embedding size is fixed to 64 and λ is set as from 1e-2 to 1e-3, the model performance increases greatly, and reaches the best when λ is 1e-4. However, when λ is greater than 1e-4, the performance will decrease, which indicates that excessive regularisation will have a negative impact on the model training.

Figure 5. Impact of the regularisation coefficient λ.

6. Conclusion

This paper proposed an API recommendation method based on a lightweight GCN, which exploits the high-order interactions between users and APIs. By adapting the classic GCN and focusing on the neighbourhood aggregation, the network model is easy to train while still keeping high effectiveness. Extensive experiments on a real-world dataset demonstrate that our method is significantly better than other baseline methods in terms of Recall@K and NDCG@K. The current work only exploits the interaction data between users and APIs for API recommendations. In practice, APIs or users probably have rich meta-data that describe their properties. In the future, we plan to take into consideration API category and provider information to further improve the API recommendation performance.

Acknowledgment

The work described in this paper was supported by the National Natural Science Foundation of China (No. 61976061 and No. 62102461), and the Natural Science Foundation of Fujian Province (No. 2022J05106).

Disclosure statement

No potential conflict of interest was reported by the author(s).