Digital Communications and Networks(DCN)

journal homepage: www.elsevier.com/locate/dcan

Diversified and Compatible Web APIsRecommendation in IoT

Wenwen Gonga, Huiping Wub, Xiaokang Wangc, Xuyun Zhangd, Yawei Wanga

Yifei Chen∗a, Mohammad R. Khosravie, faColleage of Information and Electrical Engineering, China Agricultural University, Beijing 100000, ChinabBlockchain Laboratory of Agricultural Vegetables, Weifang University of Science and Technology, Shouguang 262700, ChinacDepartment of Computer Science, St. Francis Xavier University, Antigonish, NS, CanadadDepartment of Computing, Macquarie University, Sydney NSW 2122, AustraliaeDepartment of Computer Engineering, Persian Gulf University, Bushehr 7516913817, Iranf Department of Electrical and Electronic Engineering, Shiraz University of Technology, Shiraz 71557-13876, Iran

Abstract

With the ever-increasing popularity of Internet of Things (IoT), massive enterprises are attempting to encapsulate their devel-oped outcomes into various lightweight web APIs (application programming interfaces) that can be accessible remotely. Inthis situation, finding and composing a list of existing web APIs that can corporately fulfill the software developers’ functionalneeds have become a promising way to develop a successful mobile app, economically and conveniently. However, the bigvolume of candidate IoT web APIs put additional burden on the app developers’ web APIs selection decision-makings, sinceit is often a challenging task to simultaneously guarantee the diversity and compatibility of the finally selected a set of webAPIs. Considering this challenge and latest successful applications of game theory in IoT, a Diversified and Compatible webAPIs Recommendation approach, namely DivCAR, is put forward in this paper. First of all, to achieve API diversity, DivCARemploys random walk sampling technique on a pre-built “API-API” correlation graph to generate diverse “API-API” correlationsubgraphs. Afterwards, with the diverse “API-API” correlation subgraphs, we model the compatible web APIs recommenda-tion problem to be a minimum group Steiner tree search problem. Through solving the minimum group Steiner tree searchproblem, manifold sets of compatible and diverse web APIs ranked are returned to the app developers. At last, we design andenact a set of experiments on a real-world dataset crawled from www.programmableWeb.com. Experimental results validatethe effectiveness and efficiency of our proposed DivCAR approach in balancing the web APIs recommendation diversity andcompatibility.

© 2015 Published by Elsevier Ltd.

KEYWORDS: Internet of Things, web APIs Recommendation, diversity, compatibility

∗Yifei Chen (Corresponding author) is with Colleage of In-formation and Electrical Engineering, China Agricultural Uni-versity, Beijing 100000, China and will handle correspondenceat all stages of refereeing and publication, also post publication(email:glhfei@cau.edu.cn).

1Wenwen Gong is with Colleage of Information and ElectricalEngineering, China Agricultural University, Beijing 100000, China(email: wen.gong@cau.edu.cn).

2Huiping Wu is with Blockchain Laboratory of Agricul-tural Vegetables, Weifang University of Science and Technology,Shouguang 262700, China (email: wuhp760731@wfust.edu.cn).

3Xiaokang Wang is with Department of Computer Science, St.Francis Xavier University, Antigonish B2G, Canada (email: xk-wang@stfx.ca).

4Xuyun Zhang is with Department of Computing, Mac-

1. Introduction

Internet of Things (IoT) describes the seamless in-terconnectivity among machines and human devices

quarie University, Sydney NSW 2122, Australia (email:xuyun.zhang@mq.edu.au)

5Yawei Wang is with Colleage of Information and Electrical En-gineering, China Agricultural University, Beijing 100000, China(email: yaweiwang@cau.edu.cn).

6Mohammad R. Khosravi is with Department of ComputerEngineering, Persian Gulf University, Bushehr 7516913817, Iranand Department of Electrical and Electronic Engineering, Shi-raz University of Technology, Shiraz 71557-13876, Iran (email:m.khosravi@mehr.pgu.ac.ir)

arX

iv:2

107.

1053

8v2

[cs

.SI]

11

Aug

202

1

2 Wenwen Gong, et al.

which gather and share massive information. With thewide adoption of IoT, Service-oriented Architecture(SoA) and other novel technologies, the latest decadehas witnessed the birth of web service sharing plat-forms, such as online www.programmableWeb.com7,which hosts a wide variety of lightweight web APIs(Application Programming Interfaces) published byvarious services vendors [1]. Up to September 2020,the largest web APIs ecosystem, programmableWeb,gathers at least 23,612 published web APIs belong-ing to more than 400 predefined categories. All thesesharing platforms usually offer the external invocationfunction of published web APIs to developers [2]. Forapp developers, development cycle and cost can besaved by reusing remotely these third-party web APIs[3] and combining a few of them into value-added ap-plications [4].

Benefiting from IoT applications in various fields,the continuous evolution of the web API economy al-lows developers to find desired web APIs and fur-ther integrate them into a mashup in IoT by resort-ing to exact keyword-matching techniques [6]. How-ever, the massive candidate web APIs with similarfunctionality but distinct quality would often makeit hard for app developers to select the suitable webAPIs, especially for those developers who do not havemuch background knowledge of web APIs. For ex-ample, if a developer intends to accomplish an appwith three functions {“Video”, “Blogging”, “Pho-tos”}, he/she will search for a set of collectively-satisfied candidate web APIs over 23,612 web APIsfrom the programmableWeb.com repository throughfeeding in these three keywords successively. Then,the website would respectively return corresponding1087, 753 and 661 functional-qualified web APIs,which means that such app would require exhaustiveexploration of nearly 10003 web API compositions.As many researchers have pointed out, finding the op-timal one from so many combinations is known asclassical NP-hard [7, 8]. In this case, how to recom-mend top-K compositions to app developers remainsa non-trivial task. Therefore, it happens that there isa rapid growth in the need for recommendation sys-tem (RS) technique [9] to fulfill multifarious softwareproducts including apps.

Although a large body of efforts have been made incurrent researches in this field, we still identify severaldeficiencies:

(1) First of all, there is a significant lack of diver-sity8 [10] in existing methods since most of them placetoo much emphasis on accuracy. Moreover, they usu-ally exhibit the redundant web APIs owing to sharing

7http://www.programmableweb.com8There are two kinds of diversity in recommendation system:

aggregate or individual diversity. The aggregate diversity is for allusers across all recommended items while the individual diversity isfor each individual user. Here, our focus is on the aggregate diver-sity.

uniform web APIs in web APIs recommendation lists.This repetitive invocations for identical web API eas-ily result in decreasing the rate of customer’s satisfac-tion and increasing cost of a little extra resource tosome extent.

(2) In the second place, taking into account the tensetime-to-market limit, it’s impractical for app develop-ers to inspect the official mannuals of all potentially-possible web APIs and confirm the compatibility be-tween them. Thus, top-K combinations with the samefunctionality but distinct compatibility are different tocatch, which is prone to reduce the usefulness of rec-ommendations and the productivity of developers.

Recently, game theory, as an model of strate-gic interaction among rational decision-makers, hasbeen widely applied to various problems in IoT, suchas allocate resources, assign tasks and so on. Inview of these two limitations for automatic app de-velopment, we put forward a novel Diversity-awareand Compatibility-driven web APIs Recommendationmethod (called DivCAR) in this paper. Our contribu-tions of this paper are chiefly summarized as follows:

(1) We introduce the idea of sampling to achieve thediversity of web APIs recommendation. To the bestof our knowledge, this is the first effort to combinethe idea of sampling with minimum group Steiner treesearch algorithm for the diversity of web APIs recom-mendation.

(2) We conduct an effective web APIs recommen-dation algorithm to return the top-K useful compo-sition solutions in terms of comprehensive diversity-accuracy measure.

(3) We performed a series of systematic experi-ments over a real-world dataset crawled from the web-site programmableWeb.com, and then exported experi-ment results reveal the superiority of our proposal thancomparision methods.

The remainder of our paper is structured as follows.Section 2 investigates and classifies relevant researchworks. In order to better facilitate an understanding ofour approach, a motivating example is described intu-itively in Section 3. Key notations and their meaningsrequired by our algorithm are presented in section 4.Our recommendation solution DivCAR, in Section 5,is discussed in detail. In Section 6, we verify the ef-fectiveness of our approach through the exported ex-perimental results. Last but not least, Section 7 drawsa conclusion and points out future work.

2. Related Work

In recent years, a growing number of scholars havedevoted themselves to the multi-angle researches onweb APIs-based app development from theoretical re-search to practical application in IoT, which lays asolid groundwork for our solution. In this section,we would summarize existing literatures on web APIs

Diversity-aware Web APIs Assignment and Recommendation for Mashup Creation based on Game Theory in IoT3

recommendation for app creation from the perspec-tives of accuracy, diversity and compatibility.

2.1. Accuracy-oriented Recommendation

The accuracy in IoT web service ranking or recom-mendation has been highly concerned by researchers[11, 12, 13]. In the reusable composition context, Yaoet al. propose a probabilistic matrix factorization ap-proach with implicit correlation regularization to ex-plore web API recommendation for mashups. Ex-perimental results over a large-scale real-world ser-vice dataset demonstrate that their method outper-forms the state-of-the-art collaborative filtering ap-proaches in terms of accuracy. In [3], Hao et al. putforward a method named targeted reconstructing IoTservice descriptions (TRSDs) for the sake of morevaluable information hidden in mashup description;then, according to that, a novel service recommen-dation algorithm is developed to advance accuracy by6.5%. Afterwards, to improve the quality of the rec-ommendation results, Zhong et al. [14] enhance theabove approach by dynamically reconstructing objec-tive service profiles and design a novel recommen-dation strategy based on similar profiles. A topic-adaptive web APIs recommendation method integrat-ing multi-dimensional information, called hierarchi-cal Dirichlet processes-factorization machines (HDP-FM), is proposed in [15], which achieves a good ac-curacy performance in terms of precision, recall, F-measure and NDCG. Deep learning is introduced in[16] for web service recommendation by Xiong andWang et al.; in concrete, the complex invocation in-teractions are integrated into a deep neural networkthrough combining collaborative filtering and textualcontent to bring forth improvement at precision rate.Like this work, [17] also utilizes deep learning andmatrix factorization to do an in-depth mining of tex-tual item content. Recently, Huang et.al [18] introducea novel deep reinforcement learning-based approachto deal with the long-term recommendation problemin IoT, which significantly outperforms existing meth-ods in terms of Hit-Rate and NDCG. Besides, [19]concerns security in android applications. However,accuracy is often not the only focus of app developersin evaluating the recommended web APIs. Therefore,it is also of practical significance to explore other im-portant recommendation performance criteria besidesaccuracy.

2.2. Diversity-oriented Recommendation

Diversity, a key mertric for evaluating the recom-mendation performances in IoT settings, can signifi-cantly expand the end users’ service selection scopeand as a result, enhance the end users’ satisfactiondegree [10]. To name a few, through clustering,a category-aware distributed service recommendation(CDSR) model is put forward in [20] based on anapp requirements in the form of textual input. This

method not only enhances the accuracy to some ex-tent but also gains better diversity in long-tail recom-mendation. Similarly in [21], following the idea “ser-vices should be recommended cooperatively, not indi-vidually”, the authors of [22] continue to extend theirwork by exploiting the variant vKmeans cluster tech-nique based on K-means algorithm and updating ser-vice ranking mechanism. Then, a novel frameworkfor service set recommendation (SSR) is proposed toprovide more diverse recommendations for develop-ers. Literature [23] brings forth a service packagerecommendation (SPR) to produce recommendationswith more selective scope by exploiting a similar dis-course analysis technique in [22]. To generate a list ofdiverse web APIs, Kang et al. [24] incorporate func-tional similarity, QoS (Quality of Service) values [25]and diversity features of web services into a web ser-vices graph to rank web service diversity degree. Fi-nally, top-K web services with sound diversity are re-turned app developers. However, the above-mentionedapproaches can only a set of web services, instead ofoutputting multiple sets of web services, which oftennarrows users’ web services selection scope. Consid-ering this drawback, Cheng et al. [26] refine the pre-vious work in [24] to find more diverse web serviceslists. Different from [24] where each node in web ser-vice graph is an individual web service, the each nodein [26] is web service lists. In addition, Gu et al. [27]propose a novel diversity-optimization method basedon a time-sensitive semantic cover tree (T2SCT) tomake diversified recommendations with pretty littlecompromise on accuracy. Then, to achieve both ac-curcy and diversity, He et al. [28] use Matrix Factor-ization (MF) to predict useful third-party web APIs forapp development. Recently, a novel method called Di-vRec LSH is proposed in [29] to achieve diverse andefficient recommendations through Locality-SensitiveHashing (LSH) technique. Although the above solu-tions can achieve diverse recommendations, they of-ten suffer from low compatibility of returned web ser-vices, which makes application development less suc-cessful.

2.3. Compatibility-oriented Recommendation

In IoT web APIs-based app creation, compatibilityis often a critical metric to measure that the collabora-tion performances among web APIs and hence gainsever-increasing attention. Here, we need to point outthat plus papers [30], [28] and [26], the next few recentapproaches to be explained are all based on the co-invocation data in IoT scenario. And the same is trueof our research in this paper. In [31], the correlationgraph describing web APIs is modeled to excavate thecompatibility-aware evolution patterns of web APIs inIoT environment. The authors exploit a quantitativemethod of tag-based semantic matching-degree be-tween inputs and outputs of two web APIs to evaluatethe web API compatibility. However, this method as

4 Wenwen Gong, et al.

well as the measurement in [32] are prone to introduceunless edges when modeling the service correlationfor such input/output-based compatibility evaluation.Inspired by this issue, Qi et al. [33] have made greatefforts to define a new compatibility metric which an“API-API” correlation graph is established. Finally,combined with minimum group Steiner tree search ap-proach, a compatibility-aware APIs recommendationmethod is proposed to return a set of functionally-qualified web APIs with high-level compatibility. Af-terwards, in [34], an updated weighted APIs correla-tion graph is put forward through introducing edges’weights (lager is better). Furthermore, the authorsof [34] propose a weight-aware compatibility webAPIs recommendation method. Nevertheless, theseapproaches fail to provide developers with multiplesets of compatible web APIs. To cope with this is-sue, in [35], Gong et al. continue to make effortsin accomplishing a keywords-driven web APIs grouprecommendation, which could deliver multiple setsof IoT web APIs which are functional-qualified andcompatibility-guaranteed.

However, work [35] still suffers from a low diversityacross multiple web APIs recommendation lists as itcannot traverse as more nodes and edges bridging webAPIs as possible in the web APIs correlation graph.In view of this drawback, in this paper, we developa diversity-aware and compatibility-driven web APIsrecommendation solution based on the game theory,called DivCAR, via exploiting the sampling technique[36] to carry out more comprehensive coverage of thewhole search space. Specific details will be elaboratedin Section 5.

3. Motivating Example

In this section, we present a real-world IoT examplein Figure 1 to clarify the motivation of our research.As shown in Figure 1, a developer, i.e., Grace, intendsto develop a mobile taxi-hailing app [37] that can aidpassengers to quickly find an available taxi. Gener-ally, this app often involves four sub-functions: map-ping, messaging, navigating and payment. Thus, whendeveloping such a mobile taxi-hailing app, Graceneeds to enter a set of keywords, {“Mapping”, “Mes-saging”, “Navigating”, “Payments”} into web APIssearch engines (ProgrammableWeb.com) to search fora set of qualified APIs that can collectively satisfyGrace’s functional requirements. Here, Figure 1 ex-hibits the candidate web APIs for each keyword aswell as their possible combinations (marked by vari-ous colors).

However, in the above keywords-driven mobile appdevelopment scenario, two challenges are often raised.First of all, Grace may know little about the compat-ibility among the returned web APIs by the APIs rec-ommender system, while less-compatible web APIsmay lead to a high failure rate when composing these

APIs into a complex app. Therefore, from the per-spective of Grace, it is becoming a necessity to guar-antee that the returned a set of web APIs are not onlyfunctional-qualified but also compatible enough. Sec-ond, to provide Grace more flexibilities when choos-ing appropriate web APIs, it is significant for the rec-ommender system to return multiple sets of qualifiedAPIs, instead of only one set of APIs. This way, Gracecan pick out her preferred API set from multiple can-didate sets, so as to reduce the APP development costand accelerate the development speed.

As a result, in this situation, how to recommendmanifold diversity-aware web APIs lists with func-tionality and compatibility guarantee is becoming achallenging and meaningful issue that deserves inten-sive research.

4. Problem Definition

In the following section, we summarize the ratio-nale of necessary terms for the process of web APIsrecommendation solutions in IoT settings. Key nota-tions and their meanings are presented in Table 1.

Definition 1 (Web APIs Ecosystem): A IoT webAPIs ecosystem saves plentiful web “APP-API” inter-action information. Here, a IoT web APIs ecosys-tem, is defined as S = (API, A) where API =

{api1, api2, ..., apin} and A = {a1, a2, ..., am} denotethe collection of web APIs and apps in the IoT webAPIs ecosystem (i.e., ProgrammableWeb.com) sepa-rately. An “APP-API” co-usage record si ∈ S exists oncondition that some web API apii ∈ API is success-fully invoked in an app ai ∈ A by an app developer.

Definition 2 (Keywords Query): Given a IoT webAPIs ecosystem S , keywords query is denoted as Q =

{q1, q2, ..., qr} from category attribute of web APIs inS , which represents the end-users’ functional require-ments for expected apps.

Definition 3 (Vertices): A collection of vertices isrepresented by V = {v1, v2, ..., vn} corresponding to aset of web APIs API in web APIs ecosystem S , inwhich each vertex covers a group of keywords query{q1, q2, ..., qr}.

Definition 4 (Edges): Given a cluster of verticesV = {v1, v2, ..., vn}, there are a set of correspondingedges defined as E = {e1, e2, ..., es} (s ≤ n). If a pairof vi and v j have ever been appeared in an identicalapp, an edge e(vi, v j) is added into set E. That is tosay, suppose each app ai ∈ A invokes all web APIs inAPI and a complete graph associated with the clusterof vertices V = {v1, v2, ..., vn} would be acquired.

Definition 5 (Compatibility): In this paper, one ofthe facets that interest us is the number of times that apair of vi and v j have ever been integrated successfullyinto identical app according to historical app develop-ment, which is called as the compatibility value ci, j (aninteger greater than zero) of an edge e(vi, v j). In someways, the value of compatibility for an edge reflects

Diversity-aware Web APIs Assignment and Recommendation for Mashup Creation based on Game Theory in IoT5

Google Maps Bing Maps … 1338 APIs

APIs repository

Com Messaging Respond.io … 1726 APIs

IVA Video Sezion Video … 1087 APIs

Pin Payments Paypal Payments … 1588 APIs

Grace

Fig. 1: A motivating example of web APIs recommendation for app creation in IoT.

the weight or popularity between the two web APIs al-lied to an edge. As depicted in Figure 2, c2,3>c3,4, thenwe can draw the conclusion that v3 has better compat-ibility with v2 instead of v4. At this level, the granular-ity of web APIs versions and so on is out of the scopeof this article.

Definition 6 (Diversity): Assume that two sets ofweb APIs collection API1, API2, there is a diversityvalue D = 1 − |API1∩API2 |

|API1 |+|API2 |indicating the degree to

which the web APIs from API1, API2 are not sim-ilar to some extent. For example, considering twoweb APIs collections API1 = api1, api2, api3, API2 =

api1, api4, the diversity value equals to 0.8.Definition 7 (Weighted Web APIs Correlation

Graph (W-ACG)): Each app published on the Pro-grammableWeb website indicates a meaningful inte-gration for constituted web APIs. Above definitionsand such valuable information allow a web APIs cor-relation graph W-ACG = G(V, E, W) quoted from [34]to be established offline. Specifically, we employ theexample in Figure 2 to explain for easing readers’ un-derstanding. In this example, there are a total of 10vertices where each vertex Ai(∈ A)(0 ≤ i ≤ 9) (markedin dark orange) represents a web API covering a col-lection of functional keywords, e.g., A3 possesses thekeywords describing functions {q1, q4, q12} while A0can fulfill the function set {q7}. There exists an edgebetween these two vertices with a compatibility of0.25 that is taken reciprocal, which says the weightbetween is 4 and they have ever been integrated col-lectively four times. Note here that the “Ai” in Figure2 is shortened to “i” for brevity’s sake.

In addition, as you can see in Figure 2, there are twounconnected subgraphs due to a fraction of IoT webAPIs from different domains, e.g. print service andhealth. In the real world, it would be almost impossi-

ble for an app developer to enter such irrelevant key-words that belong to different domains. Therefore, themaximal connected subgraph serves as our W-ACG.

{q1, q4, q12} {q5, q7}

{q1, q8} {q3, q6}

{q1, q10} {q3, q6}

{q1, q2} {q7}

{q9} {q2, q5, q11}

3 2

1

0

4

5

6

7 8

9

3

1

1

1

1

1 1

1 1

1 1

1 4 3

1

1

1 1 1

1

1

Fig. 2: The partial weighted web APIs correlation graph.

As a result, our recommendation problem can beformalized as follows: given a set of keywords queryinstances Q in the web APIs ecosystem S , it requiresus to find a set of potential web APIs compositionswith minimum compatibility C while guaranteeing ac-curacy and diversity constraints P, which can be de-scribed as in (1):

Maximize C satisfying P

C = {C1, ...,CK} ,Cl = Capi1 + ... + Capin , l ∈ {1, ...,K}P = {P1, ..., PK} , P1 ≥ ... ≥ PK

(1)

6 Wenwen Gong, et al.

Here, APIi, API j ∈ {API1, ..., APIK} means two ar-bitrary recommended web APIs lists from web APIscompositions {API1, ..., APIK}. Constraints P meansputting accuracy first. That is, diversity is consideredwhen the accuracy of the list is the same since diver-sity is ensured during the sampling process in Step 1.

Table 1: Specification of symbols used in this paper

Symbol SpecificationS = (API, A) A web APIs ecosystem

API The web APIs collection

A The collection of apps

Q A sequence of required keywords

V The vertex collection

E The undirected edge collection

W The weight collection

G(V, E,W) Weighted web APIs correlation graph

Gsam A cluster of subgraphs {G1, ...,Gz}

p The size of each sample

Q′ ⊆ Q A state of Q in our model

Nkey A pre-built keyword nodes set

N Set The neighboring nodes set of vi

Nsam The collection of sampled vertexes

RThe priority queue recording transitive

trees

RTThe priority queue recording candidate

trees

STThe list of optimal trees from each

subgraph

T (vi,Q′) A status in our algorithm

Tmin(vi,Q) Minimum group Steiner tree

Tdiv Diverse top-K Steiner trees

5. Our Recommendation Solution: DivCAR

Our recommendation solution DivCAR, in this sec-tion, is discussed in detail. Before we get into the de-tails, let’s first describe the Steiner tree in subsection5.1, a key technique used in the solution. And then,the specific steps of our recommendation approach Di-vCAR are depicted in subsection 5.2.

5.1. Steiner tree

The Steiner tree (ST) or minimum Steiner tree,named after Jakob Steiner, refers to a combinatorialoptimization solution and has been proven to be com-putationally hard and NP-complete [38, 39]. The

Algorithm 1: DivFinder-Sampling (G, Q)Input:G(A, E, W): weighted APIs correlation graph;Q = {q1, . . . , qr} : a set of query keywordsOutput:Gsam = {G1, · · · ,Gz} : a cluster of weightedcorrelation subgraphs

1 Nkey = generate nodes(G,Q)2 for each i ∈ z do3 Nsam = ∅

4 randomly select a node vi from Nkey

5 add vi into Nsam

6 update Nsam

7 while |Nsam|< |Gi| do8 N Set = ∅9 if wvi,v j>0 then

10 add v j into N Set11 update N Set12 end13 randomly select a neighbor Ni from

N Set into Nsam

14 add Ni into Nsam

15 update Nsam

16 end17 build new subgraph Gi using Nsam

18 end19 return Gsam = {G1, · · · ,Gz}

Steiner tree problem is superficially similar to the min-imum spanning tree problem, in that both of them in-terconnect a given set of vertexes by a graph of short-est length, where the length is the sum of the lengthsof all edges. It has been proven that the shortest in-terconnect is exactly a tree. However, the differencebetween them is that extra intermediate vertexes andedges could be added into the graph in the Steinertree problem in order to reduce the length of the span-ning tree. In other words, the minimum spanning treecan be recognized as a special case of the minimumSteiner tree.

Let us provide a mathematical definition of theSteiner tree. Given G(V, E, W) and V ′ ⊆ V , thenT (vi,Q′) is called a Steiner tree of V ′ in G iff both con-ditions in (1) and (2) hold: (1) keywords of one vertexin V ′ are different from those of another one from V ′;(2) Q′ contains required keywords in set Q, i.e., sat-isfying Q′ ⊆ Q. In the application scenario of thispaper, however, there is usually more than one corre-sponding node for each required keyword from Q, andthus the original Steiner tree problem no longer meetsour needs so that the group Steiner tree needs to beintroduced. The essential difference between them isthat the same keywords of distinct vertexes in V ′ ex-ist. We will consider the example in Figure 2, sup-posing that Q = {q1, q2, q3, q5}, and then T (v2,Q′)is a Steiner tree of V ′ where Q′ = {q1, q2, q3, q5},

Diversity-aware Web APIs Assignment and Recommendation for Mashup Creation based on Game Theory in IoT7

V ′ = {v5, v1, v2} and edges are {e(v5, v1), e(v1, v2)}; fur-thermore, supposing that Q = {q1, q3, q7}, then thereare two group Steiner trees that meet the requirements,i.e., T (v2,Q′) where Q′ = {q1, q3, q7}, V ′ = {v5, v1, v2}

and edges are {e(v5, v1), e(v1, v2)}, and T (v0,Q′) whereQ′ = {q1, q3, q7}, V ′ = {v5, v1, v0} and edges are{e(v5, v1), e(v1, v0)}. In general, since there are diversegroup Steiner trees for a set of initially-given querykeywords, this allows us to searh and decide severalminimum group Steiner trees, which results in moreintricate decision-makings [40]. In the following sub-section, we explain step by step how to address thisproblem.

5.2. Diversity-aware and Compatibility-driven WebAPIs Recommendation Approach: DivCAR

Our solution aims at excavating deeply histori-cal “APP-API” invoking information from large webAPIs ecosystems S to reflect “the wisdom from thecrowd”. Specifically, from the data-driven perspec-tive, a wealth of “APP-API” invoking data storedin the web server of ProgrammableWeb.com carriesabundant invocation information between apps andtheir constituent web APIs, which provides solid back-ground knowledge for professionally building apps.To further achieve diversity across all web APIs rec-ommendation compositions, our proposed DivCAR ischiefly threefold, as presented in Figure 3. First, weexploit random walk sampling technique on a pre-established weighted “API-API” correlation graph togenerate diverse subgraphs. Second, with these var-ious subgraphs, we model the compatible web APIsrecommendation process as a minimum group Steinertree search problem on the basis of graph theory. Fi-nally, through working out the search algorithm, mul-tiple groups of compatible and diverse web APIs areranked and returned to the app developers.Step 1: Generate diverse subgraphs of W-ACG byrandom walk sampling

Our current methods [35, 33, 34] for informationretrieval based on graphs are limited to the mostfrequently-used web APIs, which hinders the diversityof recommended results. In this step, to further speedup diverse web APIs compositions, sampling strat-egy for graphs, as an effective technique thoroughlyresearched in [41], is introduced to generate optimalcoverage of W-ACG. Furthermore, to produce betterrepresentations for W-ACG, [41] answers two natu-ral questions: (a) Which sampling techniques can per-form well with various existing sampling methods; (b)How many the sample size can be. Overall, samplingstrategy based on simple random node selection couldperform well. Morover, this approach can also workwell as the sample size of the evolutionary subgraphpattern is reduced to approximately 15 percent of theoriginal graph, which will be verified in Section 6.

Concretely, we employ an open-source Python li-brary that consists of more than twenty algorithms

q1

q2

…

Step 1 Little Ball of Fur

…

𝑇𝑚𝑖𝑛1 𝑇𝑚𝑖𝑛𝑧 …

Step 2 Step 2

ST = {𝑇𝑚𝑖𝑛1 …, 𝑇𝑚𝑖𝑛𝑧}

Step 3 Top-K optimal web API lists

Offline Phase

Online Phase app developer

subgraph1 subgraphz

Fig. 3: Working procedure of DivCAR.

for graph sampling, Little Ball of Fur [42], to attainmultiple subgraphs. In a nutshell, it can be calleda Swiss Army knife for sampling tasks from graphstructured data. In the first place, Little Ball of Fur isdeveloped through various techniques for node, edge,and exploration-based graph sampling. In the secondplace, it provides a unified application public interfacewhich makes the application of sampling algorithmstrivial for end-users. The most attractive advantage ofLittle Ball of Fur is that it can leave the vertex indexvalues unchanged.

In consideration of the characteristics of our dataset,the Random Walk Sampler among them is allowedto serve for our algorithm. Moreover, we all knowthat this often results in a great number of samplingtimes if we expect to gain representative and desiredresults, due to the inherent uncertainty and probabilityof sampling technique. Without loss of generality, inthe experimentation of this paper, we sample each setof keyword query sequences Q = {q1, q2, ..., qr} 100times by Random Walk Sampler of Little Ball of Furbased on the prebuilt W-ACG, which is representedby {G1, · · · ,G100}. We will analyze the influence ofsampling times z on the experimental results in detailin Section 6. To ensure better understanding, we useAlgorithm 1 to elaborate the details.

8 Wenwen Gong, et al.

In addition, since each web API from the pro-grammableWeb sharing platform often possesses mul-tiple tags that represent its functions, we collect thesetags of all web APIs integrated in each app to formdistinct sets of query keywords. What needs to be em-phasized here is that all of these groups of query key-words are established in advance. In the meantime, allcorresponding subgraphs can be built offline to ensureexecution efficiency. Once these subgraphs have beenbuilt offline, they will remain relatively stable and canstill be updated with minimal overhead.

Step 2: Compatibility-aware web APIs recommenda-tion online

In the second step, according to end-users’ re-quired keywords online, our algorithm will return acompatibility-optimal web APIs composition based oneach of 100 subgraphs obtained by Step 1. For in-stance, T (v0,Q′) and T (v2,Q′) in Figure 2 mentionedpreviously. That is to say, given a query Q, this stepof DivCAR returns a compatibility-optimal minimumgroup Steiner tree, Tmin(vi,Q), rooted at vi, while cov-ering each requirement in Q. To be specific, we willstate the details below. Here, please note that it is nec-essary to convert the compatibility value by taking theinverse of ci, j of edge e(vi, v j) since our object is totry our best to obtain the “minimum value” case ofcompatibility-aware optimization problem as formu-late in equation (1).

A1

{q10

}

{q4}

{q8}

{q3} {q

2, q

5}

{q11

, q12

}

{q1, q

7} {q

6} {q

2, q

3}

1 1/5

1/2

1/4

1/3 1/2 1

1/2 1/3

1/2

1/3

1

6

2

3

4 5

7

8

9 1

1 1 1 2 2 2

3 3 3

5 5 5

6 7 8

√

2 2 1 1

3 3 3

1/

2

1/3 1/2 1/3

Fig. 4: The tree growth and tree merging processes: an example.

As depicted in Algorithm 2, according to the theoryof the Steiner tree, there are two crucial operations:tree growth and tree merging, which are described bylines 15-19 and 21-28 of Algorithm 2, respectively.Let us illustrate them with the example in Figure 4.Concretely, assume that an app developer is entitled toenter a set of required keywords Q = {q1, q3, q5, q6}.Let the descending priority queues R,RT save possibletrees and final trees, respectively.

As shown in Figure 4, a transition tree T (v5,Q′)where V ′ = {v1, v2, v3, v5} and Q′ = {q1, q5, q6} (key-words are shown in bold) appears at some point in our

Algorithm 2: DivFinder-DivSearching (Gsam,Q)

Input:Gsam = {G1, · · · ,Gz} : a cluster of weightedweb APIs correlation subgraphs;Q = {q1, . . . , qr} : a set of query keywordsOutput:S T = Tmin1 , · · · ,Tminz : a list of minimum groupSteiner trees answered from all of subgraphs.

1 R = ∅,RT = ∅

2 for each Gi ∈ Gsam do3 for each vi ∈ V do4 Q′ = Q ∩Cvi

5 if Q′ , ∅ then6 enqueue newtree T (vi,Q′) into R7 end8 end9 while R , ∅ do

10 dequeue R as T (vi,Q′)11 if Q′ = Q then12 enqueue T (vi,Q′) into RT13 continue14 end15 % the growth operation for one tree16 for each u ∈ U(vi) do17 if wu,vi + wT (u,Q′)<wT (vi,Q′) then18 T (vi,Q′) = e(u, vi) + T (u,Q′)

enqueue T (vi,Q′) into R19 end20 end21 % the merging operation for one tree22 for each T (vi,Q′1),T (vi,Q′2) do23 if Q′1 ∩ Q′2 = ∅ then24 if

wT (vi,Q′1) + wT (vi,Q′2)<wT (vi,Q′1∪Q′2)

then25 T (vi,Q′1 ∪ Q′2) =

T (vi,Q′1) ⊕ T (vi,Q′2)26 enqueue T (vi,Q′1 ∪ Q′2) into

R27 end28 end29 end30 end31 Tmini = RT.top()32 add Tmini into ST33 end34 return ST

model (highlighted with light green-shaded area). Af-terwards, the algorithm continues further from threedirections (marked with different colors in Figure 4):(1) grows to v6 to produce a new tree T (v6,Q′); (2)extends v7 to produce T (v7,Q′); (3) increases v8 toproduce T (v8,Q′). As these three trees are producedwith the same keywords Q′ = {q1, q5, q6} but dis-

Diversity-aware Web APIs Assignment and Recommendation for Mashup Creation based on Game Theory in IoT9

Algorithm 3: DivFinder-Ranking (ST)Input:ST: The list of optimal trees derived from allsubgraphs;Output:Tdiv =

{Tdiv1 , · · · ,Tdivk

}: final recommendation

resulting trees1 R ST = ranking(ST)2 for each R S Ti,R S T j ∈ R S T do3 if diversityR S Ti,R S T j ≤ θ then4 add R S Ti,R S T j into Tdiv

5 update Tdiv

6 end7 end8 return Tdiv

tinct compatibility, T (v7,Q′) with optimal compati-bility is enqueued into queue R for subsequent oper-ations. Here, please note that although the requiredquery keywords have not been increased, this opera-tion is still a necessary part of the whole algorithm. Inthis case, v6, v7 and v8 are referred to as linking nodes,while v1, v2, v4, v5 and v9 are known as keyword nodes.The above process is called the tree growth operation,which is illustrated in Figure 5 (a) and formalized asFormula (2).

In general, the tree growth operation in Figure 5 (a)needs to alternate with the following process calledthe tree merging operation in Figure 5 (b), which isformalized in Formula (3). Among the trees aftergrowth, there often is at least one pair satisfying twoconditions: (1) both of them possess identical rootnodes; (2) they cover distinct query keywords. In thiscase, we can attain a better tree with more keywordsthrough merging them to speed up the search process.Likewise, taking Figure 4 as an example, T (v3,Q′1)where V ′ = {v1, v3} ,Q′1 = {q1, q7} and T (v3,Q′2)where V ′ = {v2, v3} ,Q′2 = {q6} (marked in yellow-red)also possess identical root node v3, but different key-words. Under the circumstances, we can merge theminto a better tree T (v3,Q′), where V ′ = {v1, v2, v3} andQ′ = {q1, q6}.

Such tree growth and tree merging operations pro-ceed alternately until an optimal group Steiner treeT (v9,Q) where V ′ = {v1, v2, v3, v5, v7, v8, v9} is finallyreturned. In addition, it is highlighted that if there ismore than one tree with the same keywords root at anidentical vertex, then only one tree with the best com-patibility will be left.

wTg(Ai,K′) = minu∈U(Ai)

(wT(u,K′) + wu,Ai ) (2)

wTm(vi,Q′) = minQ=Q

′

1∪Q′

2,

Q′

1∩Q′

2=∅

(wT(vi,Q′

1) + wT(vi,Q′

2))(3)

Step 3: Diversity and accuracy-aware ranking algo-rithm

By means of the previous Step 2 and Step 3, wecan acquire 100 top-level group Steiner trees based onall sampled subgraphs, and these trees represent 100different web APIs compositions. However, theoreti-cally, there must be some compositions with low accu-racy due to the contingency inherent in the samplingprocess, which requires us to rank all of them to pickout high-quality compositions. Algorithm 3 presentsthe pseudo-code of the process of ranking. Specifi-cally, they are first ranked in order of accuracy. Then,the top-K web APIs compositions where the diversitybetween each pair is greater than θ are finally returnedto app developers as the final web APIs recommenda-tion results.

6. Experiments

6.1. Experimental Configurations

In our experiments, we employ the real-worlddataset crawled from www.programmableWeb.com[33], which includes co-invocation information be-tween 6,146 apps and 18,478 web APIs. Accordingto the redundant co-usage data of the maximum con-nected graph, W-ACG is prebuilt in advance. Throughin-depth mining on the information, we conclude thatthe vast majority of apps (approximately 96%) have 2to 5 keywords. However, what needs special explana-tion here is that in the research scenario of this article,the apps that only contain two keywords, as a specialcase, will not be experimented upon. Moreover, alltags for web APIs included in apps are collected as allsorts of keyword sets to generate various subgraphsby the Little Ball of Fur library. All experiments areperformed on a laptop with identical hardware settings(Intel i5-7300 2.60 GHz CPU, 8.0 GB RAM) and soft-ware configurations (Windows 10 and Python 3.7).

6.2. Performance Metrics

In this part, we comprehensively measure the per-formance of DivCAR in terms of the following a fewwidely-utilized metrics:

(1) Mean Inter-List Diversity (MILD). Inter-listdiversity evaluates how different every two lists are onthe basis of their Hamming distance (HMD). A higherHMD implies higher diversity between each two lists.It can be calculated as follows:

HMD = 1 −C(i, j)

|RLi| +∣∣∣RL j

∣∣∣ , i, j ∈ K ∧ i , j (4)

in which |RLi| ,∣∣∣RL j

∣∣∣ represent the number of webAPIs in ith, jth recommendation lists, respectively. Be-sides, if the ith, jth recommendation lists share no com-mon web API at all, C(i, j) = 0 holds and their HMDis 1; otherwise, their HMD is 0.

10 Wenwen Gong, et al.

A1

{q10

}

{q4}

{q8}

{q3} {q

2, q

5}

{q11

, q12

}

{q1, q

7} {q

6} {q

2, q

3}

1 1/5

1/2

1/4

1/3 1/2 1

1/2 1/3

1/2

1/3

1

6

2

3

4 5

7

8

9 1

1 1 1 2 2 2

3 3 3

5 5 5

6 7 8

√

2 2 1 1

3 3 3

1/

2

1/3 1/2 1/3

(a) Tree growth

A1

{q10

}

{q4}

{q8}

{q3} {q

2, q

5}

{q11

, q12

}

{q1, q

7} {q

6} {q

2, q

3}

1 1/5

1/2

1/4

1/3 1/2 1

1/2 1/3

1/2

1/3

1

6

2

3

4 5

7

8

9 1

1 1 1 2 2 2

3 3 3

5 5 5

6 7 8

√

2 2 1 1

3 3 3

1/

2

1/3 1/2 1/3

(b) Tree merging

Fig. 5: An example for tree operations.

MILD averages the inter-list diversity across allthe recommendation lists in one experiment instance,which is calculated by the formular (5):

MILD =1

K(K − 1)

∑HMD (5)

in which K is the total number of recommendationcompositions.

(2) Inner-List Compatibility (MILC). Inner-listcompatibility measures the success rate of each rec-ommendation compositions, which is the inverse ofthe value that can be returned directly by our Steinertree algorithm. And then, MILC averages the inter-listcompatibility across all the recommendation composi-tions in one experiment instance. The larger the valueis, the higher the recommendation performance willbe.

(3) Mean Precision (MP). Precision of a recom-mendation list RLi is the ratio of correct web APIs intotal recommended list. MP is the average of preci-sion across all the recommendation compositions inone experimental instance. As formalized in formula(6), the larger the value is, the better the recommenda-tion accuracy is.

MP =1K

K∑i=1

|RLi| ∩∣∣∣RLapp

∣∣∣|RLi|

(6)

where∣∣∣RLapp

∣∣∣ denotes the amount of real-world webAPIs used in some app.

(4) Mean Recall (MR). Different from precision,recall of a recommendation list is calculated by theratio of correct web APIs in all real-world web APIs inan app. Similar to MP, larger is better. The calculationof MR is shown in formula (7):

MR =1K

K∑i=1

|RLi| ∩∣∣∣RLapp

∣∣∣∣∣∣RLapp

∣∣∣ (7)

The above metrics are calculated for each experi-ment instance, all within the range of [0, 1]; further-more, each pair of recommendation lists in each of 100experimental instances is averaged to measure the per-formance of our algorithm.

(6) Time cost. Time cost, as a key metric, iswidely-used for the recommendation efficiency; then,the lower the value is, the higher the recommendationefficiency is.

6.3. Comparative Approaches

In our experiments, we compare DivCAR with thefollowing three representative approaches that all use“APP-API” historical co-invocation records:

(1) SSR [22]: a solution that employs clusteringand text analysis techniques to find the N sets of webAPIs of N separate categories that are most similar toa developer’s functional input text descriptions. Ac-cording to popularity, similarity and correlation de-gree of distinct web APIs, the web APIs compositionswith the highest score are selected in the ranking taskwithout considering their diversity and compatibility.Thus, this method is the baseline method in our exper-iments.

(2) KC MulAGR [35]: a keywords-driven web APIsgroup recommendation for automatic app service cre-ation, which combines the Steiner tree algorithm with-out sampling with pairwise ranking based on diversityto return diverse adequate sets of web APIs.

(3) ATD JSC [26]: is an algorithm that first enu-merates all potential web APIs compositions throughgraph searching. Then, it derives the maximal inde-pendent sets (MISs) of similarity graph built from po-tential solutions to achieve top-K diverse web APIscompositions.

(4)MSD [43]: Like in ATD JSC, MSD also first enu-merates all possible web APIs compositions throughgraph searching. Then, it produces top-K diverse webAPIs compositions through solving max-sum diversi-fication problem.

To perform a more fairer comparison, the optimalparameters in the above four competitive approachesare tuned. Specially, we set diversity threshold α = 0.5for ATD-JSC and trade-off parameter λ = 0.5 forMSD. In our experiments, we conduct the four sce-narios where inputted number of keywords r are 3, 4,5 and 6, respectively. As for each scenario, we changethe values of the parameter sampling times z from 10to 100 in steps of 10, which determines the number

Diversity-aware Web APIs Assignment and Recommendation for Mashup Creation based on Game Theory in IoT11

of sampled subgraphs. And we also vary the param-eter sampling size p, which indicates how many thenumber of vertexes in each subgraph are sampled byDivCAR.

6.4. Experimental Results

In this subsection, we verify the superiority of ourDivCAR with respect to the following four profiles,where K is equal to 10 in all cases.

Profile-1: Performance convergence evaluation ofDivCAR w.r.t. sampling times z

In our DivCAR, the number of sampling, i.e., z inthe sampling process of Step 1, serves a fairly sig-nificant role in making diversified, efficient and accu-rate recommendations. The more sampling times, thehigher the probability of generating the precise rec-ommendations for a set of required keywords. Nev-ertheless, the resulting consumption will also be high.Thus, to evaluate if and how much DivCAR trades ac-curacy for efficiency, we first statistically analyze theconvergence performance of representive metrics, i.e.,precision and diversity, under the influence of param-eter z to guide our follow-up experiments.

In examining Figure 6, sampling times z arevaried from 10 to 100, and each curve repre-sents a parameter pair (p, r), where p falls into{200, 300, 400, 500, 600, 700, 800} and r belongs to{2, 3, 4, 5, 6}. Running data on precision and diversityare reported in Figure 6 (a) and Figure 6 (b), respec-tively. The MP and MILD performance are relativelyslow and basically stable at about 0.3 and 0.9 whenparameter z grows to 100, respectively. Therefore, oursubsequent experiments are based on the fact that z isequal to 100 instead of no greater value of z.

Profile-2: Diversity comparison of the five methodsAs we discussed in the previous section, diversity

is the top priority of our research. On the one hand,a lower diversity may lead to loss of users’ satisfac-tion degree and interests. On the other hand, a largerdiversity may consequently increases its recommen-dation success rate. To measure the diversity per-formance of DivCAR in terms of the interlist diver-sity (MILD) metric, we vary value of r from 3 to 6in this test. Figure 7 presents the averaged statisti-cal data of the exported results with z = 100, p ∈{100, 200, 300, 400, 500, 600, 700, 800}. Likewise, thefollowing three profiles, i.e., profile-3, profile-4 andprofile-5 are also averaged.

As indicated in Figure 7, not surprisingly, the valueof mean interlist diversity (MILD) of our DivCAR isobviously superior to SSR by 65.81%, KC MulAGRby 22.71% and ATD JSC by 22.8% on average acrossfour cases with different r, respectively. This comesfrom the sampling mechanism introduced in our Di-vCAR, which makes good use of DivCAR’s ability tolevarage the randomness of the sampling process to

guarantee the nonrepeatability of web APIs across dis-tinct recommendation lists. To a certain extent, thisavoid the so-called local optimum dilemma in the op-timization problem. In addition, we can see that thebaseline SSR remains largely lower than other threemethods, which confirms that the diversity of its algo-rithm needs to be further improved. In contrast withthis, the MILD values of KC MulAGR and ATD JSCare lower than that of DivCAR since KC MulAGRonly utilizes the minimum group Steiner tree algo-rithm without sampling technique. And thus, as forimproving the dilemma of local optimum, they don’twork very well. Furthermore, from Figure 7, it can bedrawn that the performance of our method is compara-ble to that of the MSD method in terms of MILD value,but the accuracy of MSD was significantly worse thanthat of our proposal.

Figure 7 also shows that, when the number of rrises, the overall MILD data of these five approachesroughly decline. For example, one of the most obviousis that KC MulAGR decrease from 76.32% to 58.92%and ATD JSC decrease from 75.98% to 58.91%. Thisis mainly because of the fact that more web APIs in-crease the likelihood of repetition among them. There-fore, more distinct web APIs can be recommendedto app developers to improve the satisfaction andserendipity of recommendations through our DivCAR.DivCAR offers significantly global diversity of the webAPIs across individual recommendation lists by sam-pling to give equal opportunities to both popular andless popular web APIs.

Profile-3: Compatibility comparison of the two meth-ods

Compatibility, as another goal of our study we needto guarantee, affects how many success rate a devel-oper executes. In this experiment, since compatibilitybetween web APIs is not considered in other two com-petitive methods ATD JSC and SSR, we only comparethe compatibility of trees answered by DivCAR withKC MulAGR in terms of the mean inner-list compati-bility (MILC) metric. Moreover, a larger compatibilityof a tree means better compatibility among web APIsfrom the tree. Here, r is set to an integer between 2and 6. The experimental data are shown in Figure 8.

As exported in Figure 8, there is no distinct ten-dency in MILC of DivCAR and KC MulAGR with thegrowth of r. Their values basically fluctuate around 4.The reason for this phenomenon is that one or moreweb APIs are needed to collectively meet functionalrequirements represented by distinct number of key-words. Under normal conditions, more web APIs of-ten lead to larger MILC values. In addition, there islittle difference in MILC value between DivCAR andKC MulAGR. For example, DivCAR’s MILC outper-form KC MulAGR by 0.2, 1.59, 1.52 and 0.89 when ris equal to 3, 4, 5 and 6, respectively. This shows an-other advantage of sampling technique to avoid globaloptimization. Therefore, our DivCAR can always

12 Wenwen Gong, et al.

(b) MP convergence (c) MILD convergence

Fig. 6: Performance convergence of DivCAR w.r.t. sampling times.

Fig. 7: Recommendation diversity comparison.

achieve high-level web APIs compatibility.

Profile-4: Accuracy comparison of the five methodsIn this part, we evaluate and compare the recom-

mendation accuracy of five methods by measuring theMP and MR metrics, which are recognized as the keymeasurements for evaluating the probability of “False-positive” and “False-negative”, respectively. The sta-tistical experiment results are indicated in Figure 9.

As displayed in Figure 9 (a) and Figure 9 (b), theMP and MR values of the three methods, DivCAR,KC MulAGR, SSR and MSD, all increase with thegrowth of r. For instance, DivCAR’s MP and MRgradually increase by 9% from 23% to 32% in Fig-ure 9 (a) and by 10% from 32% to 42% in Figure 9(b), respectively. This is because the validity of rec-ommended web APIs will increase with the rise ofrequired web APIs to fulfill more complex functionalrequirements for an app. Here, what needs to be ex-plained is that the MP and MR data of DivCAR are su-

Fig. 8: Recommendation compatibility comparison.

perior to those of SSR and MSD, but perform slightlyworse than KC MulAGR and ATD JSC. This comesfrom two main reasons. On the one hand, the fact ourDivCAR outperforms SSR originates from that we uti-lize minimum group Steiner tree algorithm. On theone hand, there is a tradeoff between accuracy and di-versity needs to be adjusted according to the needs ofdifferent scenes. To better demonstrate why such bal-ance between the accuracy and diversity is the rightbalance, we defined a harmonic mean of the diversityand accuracy according to F2-score, which is calcu-lated by (1 + 4) MP∗MILD

(4∗MP)+MILD . The values of harmonicmean are 0.6107, 0.6082, 0.6002, 0.1672, 0.3826 forDivCAR, KC MulAGR, ATD JSC, SSR and MSD, re-spectively. Especially, our focus is on the diversityof web API name in research scenarios of our pa-per. To be specific, except for SSR, although the ac-curacy of KC MulAGR and ATD JSC is better thanthat of DivCAR, their diversity is not as good as that

Diversity-aware Web APIs Assignment and Recommendation for Mashup Creation based on Game Theory in IoT13

(a) MP (b) MILD

Fig. 9: Recommendation accuracy comparison.

Fig. 10: Computation time comparison.

of DivCAR. For example, DivCAR obtains significantmerits over SSR, i.e., 65.81%, 18% and 22.13% inMILD, MP and MR, respectively; DivCAR outper-forms ATD JSC in MILD by 22.8% on average, butis inferior to ATD JSC in MP and MR by 21.6% and22.62%. It’s also important to point out here that al-though the diversity of our DivCAR is comparable tothat of MSD, the accuracy is significantly better thanthat of MSD, i.e., 16% and 17% on average in MP andMR. Nonetheless, more importantly, the accuracy ofDivCAR is still able to meet the needs of developers inmost cases. Therefore, the performance of our algo-rithm can still be guaranteed.

Profile-5: Efficiency comparison of the five methods

Efficiency, as an important metric to evaluate algo-rithm performance, is tested and made a comparisonof five different recommendation methods. The con-sumed time cost of five approaches is illustrated inFigure 10.

As demonstrated in Figure 10, the time consump-tion of the five methods all increase with the number ofr. Among them, the fastest growth is especially SSR so

that it grows almost linearly. This comes from the factthat more query keywords often require more compli-cated search processes. Moreover, the time cost of SSRpresents an approximately and linearly positive cor-relation with r, since time consumption is generatedwhen candidate web APIs are clustered into r distinctcategories in the first stage of the algorithm. Amongthese approaches, the most time-consuming method isMSD as it concerns the sum of the diversity of all com-binations. With the growth of r, both KC MulAGR andDivCAR methods consume more time to find the top-K appropriate web APIs compositions from increasingnumbers of candidate web APIs. KC MulAGR needsmore or less as much consumed time as ATD JSCdoes as they all first generate all candidate result treesand then to find diverse top-K web APIs recommen-dation lists. However, it is obvious from Figure 10that the growth in consumption time of DivCAR isslightly more significant than that of KC MulAGR andATD JSC. This is because slightly more time is re-quired to find the top-K optimal solutions from fewersampled nodes in the first step of our DivCAR. Plus,the excellent diversity value of DivCAR, the time costis perfectly acceptable.

Profile-6: Recommendation performance evaluationof our DivCAR w.r.t. (z, p)

In our algorithm, the two parameters, i.e., sam-pling times z and sampling size p, can affectthe exported recommendation results. To inves-tigate their influence on DivCAR’s performance,z ∈ {10, 20, 30, 40, 50, 60, 70, 80, 90, 100} and p ∈{100, 200, 300, 400, 500, 600, 700, 800}. Therefore,we test the average accuracy, diversity, compatibil-ity and efficiency performance of our DivCAR acrossone hundred cases with different z - p combinations interms of MP, MILD, MILC and computation time, re-spectively. The experimental results are shown in Fig-ure 11, in which each line represents a change trendin the performance of p at different z and can all con-

14 Wenwen Gong, et al.

(a) MP convergence (b) MILD convergence

(c) MP convergence (d) MILD convergence

Fig. 11: Performance evaluation of DivCAR w.r.t. (z, p).

verges when z = 100.As Figure 11 indicates, as z grows, the increase in

z from 10 to 100 significantly impacts the values ofMP obtained by different sample sizes. In Figure 11(a), compared with z = 10, DivCAR achieves muchhigher performance when z>10. For instance, on av-erage across different cases with z>10, DivCAR’s MPoutperforms z>10 by 55%. As presented Figure 11(b), DivCAR is also significantly affected along withthe increase in z, but in the opposite negative way. Di-vCAR’s MILD slightly decreases by 3.34% on aver-age. On one hand, it shows that the increases in MPcan achieve much more significant than the such slightdecreases in the values of MILD. On the other hand,we can conclude that the MP and MILD performancesof our DivCAR can reach the best case when the samp-ing size p is 100. This mainly comes from that as thenumber of sampling times increases, more “appropri-ate web APIs” in each recommendation list inevitablyresult in less diversity of web APIs.

By contrast, the increase in z does not significantlyimpact DivCAR’s compatability and efficiency mea-sured by MILC and computation time, which furtherillustrates the stability of our method. More specif-

ically, in the case of a small z at the beginning, thecompatibility is not pretty stable, which is in line withour expected idea. But with the growth of z, p exactlyaffects MILC and computation time. Under differentp, all the values of MILC vary from 2 to 22 in Figure11 (c) and the values of computation time all vary from0.1 to 1.1 in Figure 11 (d). These changes are per-fectly acceptable range. In addition, computation timegradually escalates with the growth of sampling sizep, which perfectly validates our expected results. Thisis because the search processes become more compli-cated as the number of nodes in sampled subgraphsincrease. With p = 100, DivCAR produces the mostsignificant merit over other different p, i.e., 0.089 sec-onds in computation time. Lastly, it is worth notingin particular that the finding mentioned in the classicpaper [41] that sampling strategy can achieve ideal ef-fects with size down to approximately 15% of originalmassive graph, which exactly corresponds to the casez = 100 and p = 100 across all combinations.

Diversity-aware Web APIs Assignment and Recommendation for Mashup Creation based on Game Theory in IoT15

7. Conclusion

Web APIs recommendation in IoT settings has be-come a promising way for app developers to developdesirable apps quickly and effciently. However, the re-sults demonstrate that existing web APIs recommen-dation algorithms still suffer from low diversity. Toovercome this issue, in this paper, we propose Div-CAR by means of the idea of game theory in IoT andsampling technique, to achieve diversity-aware andcompatibility-driven web APIs recommendation formashup development in IoT. In DivCAR, we employa random walk sampling technique on a “API-API”correlation graph prebuilt from “APP-API” co-usagerecords to generate diverse “API-API” correlation sub-graphs. Afterwards, with the diverse “API-API” corre-lation subgraphs, we model the compatible web APIsrecommendation problem as a minimum group Steinertree search problem; moreover, through solving theproblem, manifold sets of compatible and diverse webAPIs are made available to the app developers. At last,extensive experiments based on a real-world datasetfrom programmableWeb validate the effectiveness andefficiency of our proposed DivCAR approach.

In our future work, the quality data of IoT webAPIs, i.e., response time, will be extended into our al-gorithm to imporve the recommendation accuracy. Inaddition, we will leverage more additional informationof apps and web APIs from programmableWeb, e.g.,their descriptions and versions, for more practical anddiverse apps in IoT.

References

[1] N. Almarimi, A. Ouni, S. Bouktif, M. W. Mkaouer, R. G.Kula, M. A. Saied, Web service api recommendation for au-tomated mashup creation using multi-objective evolutionarysearch, Applied Soft Computing Journal 85.

[2] B. Cao, X. F. Liu, M. M. Rahman, B. Li, J. Liu, M. Tang, Inte-grated content and network-based service clustering and webapis recommendation for mashup development, IEEE Trans-actions on Services Computing 13 (1) (2020) 99–113.

[3] Y. Hao, Y. Fan, W. Tan, J. Zhang, Service recommendationbased on targeted reconstruction of service descriptions, 2017,pp. 285–292.

[4] A. Segev, E. Toch, Context-based matching and ranking ofweb services for composition, IEEE Transactions on ServicesComputing 2 (3) (2009) 210–222.

[5] S. Bergamaschi, E. Domnori, F. Guerra, R. T. Lado, Y. Vele-grakis, Keyword search over relational databases: a meta-data approach, SIGMOD ’11: Proceedings of the 2011 ACMSIGMOD International Conference on Management of data(2011) 565–576.

[6] M. Jiang, W. C. Fu, C. W. Wong, Exact top-k nearest keywordsearch in large networks, SIGMOD ’15: Proceedings of the2015 ACM SIGMOD International Conference on Manage-ment of Data (2015) 393–404.

[7] D. Ardagna, B. Pernici, Global and local qos guarantee in webservice selection, Business Process Management Workshops1 (4) (2006) 233–243.

[8] A. Ouni, R. G. Kula, M. Kessentini, T. Ishio, D. M. German,K. Inoue, Search-based software library recommendation us-ing multi-objective optimization, Information and SoftwareTechnology 83 (2017) 55–75.

[9] W. Gong, L. Qi, Y. Xu, Privacy-aware multidimensional mo-bile service quality prediction and recommendation in dis-tributed fog environment, Wireless Communications and Mo-bile Computing, 2018, Article ID 3075849, 8 pages 2018.

[10] M. K. A, T. P. B, Diversity in recommender systems – a survey,Knowledge-Based Systems 123 (2017) 154–162.

[11] E. Al-Masri, Q. H. Mahmoud, Qos-based discovery and rank-ing of web services, https://doi.org/10.1109/ICCCN.2007.4317873 (2007).

[12] L. Yao, Q. Z. Sheng, A. Segev, J. Yu, Recommending webservices via combining collaborative filtering with content-based features, https://doi.org/10.1109/ICWS.2013.16 (2013).

[13] L. Yao, Q. Z. Sheng, A. H. H. Ngu, J. Yu, A. Segev, Unifiedcollaborative and content-based web service recommendation,IEEE Transactions on Services Computing 8 (3) (2015) 453–466.

[14] Y. Zhong, Y. Fan, W. Tan, J. Zhang, Web service recommen-dation with reconstructed profile from mashup descriptions,IEEE Transactions on Automation Science and Engineering15 (2) (2018) 468–478.

[15] L. HC, L. JX, C. BQ, S. M., Topic-adaptive web api recom-mendation method via integrating multidimensional informa-tion., IEEE Transactions on Automation Science and Engi-neering 15 (2) (2018) 468–478.

[16] R. Xiong, J. Wang, N. Zhang, Y. Ma, Deep hybrid collabora-tive filtering for web service recommendation, Expert Systemswith Applications 110 (2018) 191–205.

[17] H. Wu, Z. Zhang, K. Yue, B. Zhang, J. He, L. Sun, Dual-regularized matrix factorization with deep neural networks forrecommender systems, Knowledge-Based Systems 145 46–58.

[18] L. Huang, M. Fu, F. Li, H. Qu, Y. Liu, W. Chen, A deep re-inforcement learning based long-term recommender system,Knowledge-Based Systems 213 (2021) 106706.

[19] J. Tang, R. Li, K. Wang, X. Gu, Z. Xu, A novel hybrid methodto analyze security vulnerabilities in android applications, Ts-inghua Science and Technology 25 (5) (2020) 589–603.

[20] B. Xia, Y. Fan, W. Tan, K. Huang, J. Zhang, C. Wu, Category-aware api clustering and distributed recommendation for auto-matic mashup creation, IEEE Transactions on Services Com-puting 8 (5) (2015) 674–687.

[21] W. Gao, L. Chen, J. Wu, H. Gao, Manifold-learning basedapi recommendation for mashup creation, 2015 IEEE Interna-tional Conference on Web Services (ICWS) (2015) 432–439.

[22] W. Gao, J. Wu, A novel framework for service set recommen-dation in mashup creation, 2017 IEEE International Confer-ence on Web Services (ICWS) (2017) 65–72.

[23] Q. Gu, J. Cao, Q. Peng, Service package recommendationfor mashup creation via mashup textual description mining,2016 IEEE International Conference on Web Services (ICWS)(2016) 452–459.

[24] G. Kang, M. Tang, J. Liu, X. Liu, B. Cao, Diversifyingweb service recommendation results via exploring service us-age history, IEEE Transactions on Services Computing 9 (4)(2016) 566–579.

[25] Y. Jin, W. Guo, Y. Zhang, A time-aware dynamic service qual-ity prediction approach for services, Tsinghua Science andTechnology 25 (2) (2019) 227–238.

[26] H. Cheng, M. Zhong, J. Wang, Diversified keyword searchbased web service composition, Journal of Systems and Soft-ware 163 (2020) 110540.

[27] L. Gu, P. Yang, Y. Dong, Diversity optimization for recom-mendation using improved cover tree, Knowledge-Based Sys-tems 135 (nov.1) (2017) 1–8.

[28] Q. He, B. Li, F. Chen, J. Grundy, Y. Yang, Diversified third-party library prediction for mobile app development, IEEETransactions on Software Engineering (2020) 1–1.

[29] L. Wang, X. Zhang, R. Wang, C. Yan, L. Qi, Diversifiedservice recommendation with high accuracy and efficiency,Knowledge-Based Systems 204 (2020) 106196.

[30] L. Yao, X. Wang, Q. Z. Sheng, B. Benatallah, C. Huang,Mashup recommendation by regularizing matrix factorization

16 Wenwen Gong, et al.

with api co-invocations, https://doi.org/10.1109/TSC.2018.2803171 (2018).

[31] G. Huang, Y. Ma, X. Liu, Y. Luo, X. Lu, M. B. Blake,Model-based automated navigation and composition of com-plex service mashups, IEEE Transactions on Services Com-puting 8 (3) (2015) 494–506.

[32] N. Chen, N. Cardozo, S. Clarke, Goal-driven service compo-sition in mobile and pervasive computing, IEEE Transactionson Services Computing 11 (1) (2018) 49–62.

[33] L. Qi, Q. He, F. Chen, W. Dou, Q. Ni, Data-driven webapis recommendation for building web applications, https://doi.org/10.1109/TBDATA.2020.2975587 (2020).

[34] L. Qi, Q. He, F. Chen, W. Dou, S. Wan, X. Zhang, X. Xu,Finding all you need: Web apis recommendation in web ofthings through keywords search, IEEE Transactions on Com-putational Social Systems 6 (5) (2019) 1063–1072.

[35] W. Gong, C. Lv, Y. Duan, Z. Liu, M. R. Khosravi, W. Dou,Keywords-driven web apis group recommendation for auto-matic app service creation process, https://doi.org/10.1002/spe.2902 (2020).

[36] M. S. Mahmud, J. Z. Huang, S. Salloum, T. Z. Emara, K. Sa-datdiynov, A survey of data partitioning and sampling meth-ods to support big data analysis, Big Data Mining and Analyt-ics 3 (2) (2020) 85–101.

[37] Y. Khazbak, J. Fan, S. Zhu, G. Cao, Preserving personalizedlocation privacy in ride-hailing service, Tsinghua Science andTechnology 25 (6) (2020) 743–757.

[38] M. R. Garey, D. S. Johnson, The rectilinear steiner tree prob-lem is np-complete, SIAM Journal on Applied Mathematics32 (4) (1977) 826–834.

[39] F. K.Hwang, D. Richards, Pawel.Winter, The steiner tree prob-lem, Networks 22 (1) (1992) 55–89.

[40] N. Bhardwaj, P. Sharma, An advanced uncertainty measureusing fuzzy soft sets: Application to decision-making prob-lems, Big Data Mining and Analytics 4 (2) (2021) 94–103.

[41] J. Leskovec, C. Faloutsos, Sampling from large graphs, Pro-ceedings of the 12th ACM SIGKDD international conferenceon Knowledge discovery and data mining (2006) 631–636.

[42] B. Rozemberczki, O. Kiss, R. Sarkar, Little ball of fur apython library for graph sampling, https://doi.org/10.1145/1122445.1122456 (2020).

[43] A. Borodin, A. Jain, H. C. Lee, Y. Ye, Max-sum diversifica-tion, monotone submodular functions, and dynamic updates,ACM Transactions on Algorithms (TALG) 13 (3) (2017) 1–25.