Semantics-enabled Web API Organization and Recommendation

(1)

Devis Bianchini

, Valeria De Antonellis, Michele Melchiori

Department of Information Engineering Università di Brescia - Italy

Semantics-enabled Web API

Organization and Recommendation

(2)

Fast Web app development

:

“Deployment of situational, short-living

Web applications with focus on Web Interface integration of

components independently originated from third parties and that

are made available through Web APIs”

(3)

Fast Web application development

Which open issues?

Allowing a Web designer to explore and understand the space of available APIs:

• dynamicity of this space and large number of available APIs (>4k APIs in ProgrammableWeb.com)

• heterogeneity in Web API description

• limited time usually allocated for the development of this kind of Web applications

Our contributions:

1. A browsable registry of semantics-enriched Web APIs

2. Semi-automated selection patterns for Web APIs aggregation

(4)

Our vision

We rely on existing technologies Focus of this talk See [1]

(5)

Talk Outline

•

Web API organization in a semantics-enabled

registry

•

Web API Selection patterns

•

The prototype tool implementation

•

Conclusions and future work

(6)

Semantic annotation of Web APIs (I)

Web APIs are usually described using plain, unstructured HTML

 semantic annotation of Web APIs is still a difficult task Few efforts have been made to solve these limitations

 Web Application Description Language (WADL), to propose a counterpart of the WSDL standard for WSDL/SOAP-based Web Services (too complex, not widespread)

 Combined use of hRESTS (to structure Web API description) and

(7)

Semantic annotation of Web APIs (II)

Web APIs are usually described using plain, unstructured HTML - semantic annotation of Web APIs is still a difficult task

Semantic annotation of APIs in our framework is therefore performed according to the steps suggested in the SWEET tool [2]:

(a) identification of elements (that is, operations, inputs, outputs) in the unstructured HTML document which represents the API, to produce an hRESTS description

(b) search for ontologies suitable for elements annotation and of taxonomies of categories for API classification

(c) annotation and classification of the API according to the MicroWSMO notation

[2] M. Maleshkova, C. Pedrinaci, and J. Domingue. Semantic annotation of Web APIs with SWEET. In Proc. of 6th Workshop on Scripting

(8)

<div class=”service” id=”svc”> <p>Description of the

<span class=”label”>ACME Hotels</span> service:</p> <div class=”operation” id=”op1”><p>

The operation <code class=”label”>getHotelDetails</code> is invoked using the method <span class=”method”>GET</span> at <code class=”address”>http://example.com/h/fidg</code>, with <span class=”input”>the ID of the particular hotel

replacing the parameter <code>id</code></span>.

It returns <span class=”output”>the hotel details in an <code>ex:hotelInformation</code> document.</span>

</p></div></div>

Example hRESTS description

(9)

<div class=”service” id=”svc”> <p>Description of the

<span class=”label”

rel=“model” href=“…ecommerce.owl#hotelReservation”>ACME Hotels</span> service:</p>

The operation <code class=”label”>getHotelDetails</code> is invoked using the method <span class=”method”>GET</span> at <code class=”address”>http://example.com/h/fidg</code>, with <span class=”input”>the ID of the particular hotel

replacing the parameter <code>id</code></span>.

It returns <span class=”output”>the hotel details in an <code>ex:hotelInformation</code> document.</span>

</p></div></div>

Insertion of MicroWSMO annotations

SWEET-style annotation (II)

(10)

W

i

=

uri

i

,CAT(

W

i

),OP(

W

i

),EV(

W

i

)

ev

m

=

type

m

,OUT

ev

(

ev

m

)

ev

m

EV(

W

i

)

op

l

=

method

l

,

addr

l

,IN(

op

l

),OUT(

op

l

)

op

l

OP(

W

i

)

(11)

•

A Web API descriptor W

_i

is functionally similar

to

another Web API descriptor W

_j

if:

1.

The categories of W

_i

and W

_j

are compatible

2.

Sim

_IO

(W

_i

, W

_j

) ≥

[0..1] (functional similarity degree)

Union of the input sets of all the W_j operations

Union of the output sets of all the W_i operations

Concept affinity

Functional similarity between Web APIs

(12)

Functional coupling between Web APIs

•

A Web API descriptor W

_i

can be functionally coupled

with another Web API descriptor W

_j

if:

1.

Coupl

_IO

(W

_i

, W

_j

) ≥

[0..1] (functional coupling degree)

Union set of the outputs of the event evi

(13)

Web application development scenario (I)

Building a Web app from the scratch

– The Web designer

proceeds step by step by selecting a Web API and mapping

events with operations

1.

The designer specifies

a requested Web API

in terms of

categories, operations and/or inputs/outputs

2.

The system suggests APIs that

can be coupled with

Web

APIs already included in the Web app under construction

(14)

Search selection pattern

I need a Web API to find movie theatres

(15)

Search selection pattern

I need a Web API to find movie theatres

(16)

Completion selection pattern

What functionalities could be added to

(17)

What functionalities could be added to

my Web app?

Completion selection pattern

(18)

Modifying an existing application

– The Web designer finds an

existing Web app on the Web of Data and desires to replace

one of the component Web APIs, since

1.

they became unavailable

2.

application requirements have been changed

3.

the designer needs to improve the QoS of the Web

application

The system suggests APIs that

can substitute

Web APIs already

included in the Web app under construction

(19)

I need a different Web API to convert

coordinates

Substitution selection pattern

(20)

I need a different Web API to convert

coordinates

(21)

Web API Selection Patterns

We define a Selection Pattern

as a 4-uple

• W is the Web API descriptor to be searched for (search pattern), coupled (completion pattern), substituted (substitution pattern)

• m is the metric used to evaluate the degree of matching (search pattern), of coupling (completion pattern) or similarity (substitution pattern)

• is the threshold to filter out not relevant Web APIs

•  is a ranking function to present the suggested Web APIs

=

W

,

m

, ,

W

i



W

j

m

(

W

,

W

i

) ≥

m

(

W

,

W

j

)

(22)

Web API Selection Patterns

Goal

=

W

Goal

,

m

Goal

,

Goal

, <

Goal

,

Goal = search

Purpose: to provide the designer with APIs matching the request W_Goal,

So m_Goalis defined on the basis of Sim_IO()

Goal = completion

Purpose: to provide the designer with APIs having high coupling with the W_Goal already in the Web app

So m_Goalis defined on the basis of Coupl_IO()

Goal = substitution

Purpose: to provide the designer with APIs matching the descriptor W_Goal, already in the Web app AND having high coupling with descriptors W_Jconnected to W_Goal, in the application

(23)

Prototype: Browsing by coupling

(24)

Conclusions and future work

We proposed techniques for fast Web app development based on:

Organizing Web API descriptors according to similarity and coupling criteria

Exploiting in a semi-automated way this organization by means of selection patterns to support the application design

Future work:

Additional suggestion metrics (e.g., collective knowledge) Performing experiments on real datasets

Developing a complete framework for Web API-based development (e.g., semi-automatic generation of Javascript glue code)

(25)