CCECE 2014 1569880107

A Framework for the Service Provisioning of

Community-Contributed Web APIs
Daniel Vijayakumar

Qusay H. Mahmoud

School of Computer Science

University of Guelph
Guelph, Canada
Email: dvijayak@uoguelph.ca

Dept. of Electrical, Computer and Software Engineering

University of Ontario Institute of Technology
Oshawa, Canada
Email: qusay.mahmoud@uoit.ca
of the architecture, conditional on adherence to the interface definitions [2]. Furthermore, there is no conceptual
constraint on the scope of publishing: if desired, a
component can be made available to any interested party
on the Web. As a consequence of the above two features,
application developers are able to enhance the value of
their applications by integrating with such services to
create features that would be impossible or infeasible to
be developed in-house. Additionally, services can serve
as building blocks for the creation of more complex
services. These composite services are themselves, as
the name implies, services; this detail is abstracted away
from the service consumer.

AbstractWith the increased adoption of cloud computing in recent years due to its projected benefits as a
computing-as-a-utility paradigm, the industry has consequently seen a rise in software-as-a-service via Web services. Serving as a safe and valuable interface between the
providers data and outsider parties who have a potential
use for the data, services allow developers to enhance
the value of their applications by integrating with them.
Initially, standardization and research efforts were geared
largely towards enterprise use-cases of Web services. This
resulted in the global Web service vision becoming largely
privatized. But in recent years, the number and diversity
of Web APIs have increased tremendously and developers
have additionally become more open and decentralized.
This poses the interesting problem of aggregating the vast
number of distributed codebases and exposing them as
consumable services for the benefit of all. The existing
enterprise-oriented standards are unable to cater to such
a scenario. We respond to this by presenting an alternative
to the status quo of service registries. We specifically argue
for the feasibility of a RESTful framework for the design
and implementation of an open service registry that serves
a community of Web services that can be contributed to
or consumed by any developer on the Web.

I.

The number of extant Web services is no small

number. As of July 2013, there were at least 9500 Web
service interfaces (referred to as Web APIs) and 7100
mashups (composite services formed from composing
Web APIs [3]) registered in one of the most popular API
directories called ProgrammableWeb1 [4]. This is only
one of other similar registries and the reported statistics
are only expected to grow as more web services and
mashups come to existence. However, the literature is
almost unanimous in the view that the publishing and
discovery of services still remains an open research
problem (citation required).

I NTRODUCTION

Cloud computing has seen increased adoption over

the last decade due to its projected benefits as a
computing-as-a-utility paradigm. The infrastructure of
the Cloud is an attractive platform for distributed architectures and the industry has taken this opportunity
to propel the development of various implementations
of the service-oriented architecture (SOA). One of the
more prolific paradigms is that of Web services. A Web
service serves as an interface between some valuable
data of the entity providing the service and parties
(either external or internal) who may have an interest
in consuming this data. Emphasis is placed on abstracting away the interface definition from the underlying
implementation in order to yield a loosly coupled and
platform/language-interoperable system [1].

While standardization and research efforts have understandably been geared largely towards internal/external enterprise integration, a ripe but largely unexplored
area (to the best of our knowledge) is the rapidly
growing eco-system of decentralized and distributed
developers, such as the open source community. An
interesting research problem is how can such vastly
distributed codebases be aggregated and exposed as
easily consumable Web services. For some perspective,
the popular source code version-control service GitHub2
is single-handedly a home to more than 4 million
heterogeneous codebases [5] as of 2012.
We propose a framework for the implementation of
a globally unified registry where 1) any developer can

An important feature is the enabling of independent

components (including legacy/archaic code) within a
modern system to be seamlessly integrated with the rest

1 www.programmableweb.com
2 www.github.com

978-1-4799-3010-9/14/$31.00 2014 IEEE

CCECE 2014 Toronto, Canada

register self-sufficient pieces of code as services, 2) any

developer can discover these services, 3) any party is
able to invoke these services and consume the output,
4) any developer can create composite services using
existing services, 5) and the entire registry (including
the above four features) is exposed via a RESTful
interface.

4)
5)

Such a diverse and open conglomerate of services

offers as key benefits the openness of a collaborative
community and the simplicity and robustness of the
underlying REST architecture. This open, simplified and
scalable access lowers the barrier of entry for developers
and naturally facilitates increased innovation, the returns
of which benefit all participants of the community.

The idea of applying the principles of REST towards

Web services has received great interest throughout the
literature in recent years. It has brought about the rise
of a new paradigm known as the Resource-Oriented
Architecture (ROA) where resources are considered
first-class citizens instead of services (SOA) [8].

Our contribution to the literature would be the

demonstration of the feasibility of such a framework.
We aim to demonstrate this through the implementation
of a proof-of-concept prototype and performing empirical evaluations thereof. The scope of our research
is currently limited to the performance dimension of
feasibility, and this is what we emphasize in this paper.

In response to the vast amount of studies performed

on the status of Web services, like [9], but the lack of
exploration into comparisons of interfaces, the authors
of [10] have performed a thorough investigation of the
landscape of public Web services and their APIs. As of
July 2013, this is the only broad study performed on
Web APIs to the best of our knowledge. An important
observation is that of the usage of RESTful APIs.
Out of a representative sample of 222 services from
a 2010 crawl of ProgrammableWeb, RESTful APIs
formed only about 32% of the sample. But in a separate
2012 study [11] of the same directory, the number of
representative RESTful services doubled to 72% while
the total number of services also increased from [10].
This massive shift towards RESTful services from the
standardized WS-* stack offers insights towards API
preferences among developers.

The remainder of this paper is organized as follows:

Section 2 briefly discusses background information and
relevant literature; Section 3 presents our framework;
Section 4 describes our prototype implementation; Section 5 outlines a few practical use cases of our system;
and we conclude by identifying future work in Section
6.
II.

R ELATED W ORK

This section discusses some of the key works in the

literature that are relevant to our research.

B. Service Registries
Collaboration efforts of enterprises such as Ariba,
IBM and Microsoft who were interested in B2B
(Business-to-Business) transactions in the late twentieth
century resulted in a standard known as the Universal
Description Discovery and Integration (UDDI) [2]. It
served the role of service discovery within the wellknown WS-* stack. It was created in order to address
the then popular idea of a Universal Business Registry
(UBR). As [2] further notes, the initial goal was to
support service directories all over the world such that
any party could freely publish service descriptions as
well as query such directories for interesting services.
UDDI was much criticized even in its early days due to
the small population of services in such directories [12].
But interestingly enough, [12] defended the criticism by
pointing out that web services were not intended for
public use, but within the restricted enterprise arena.
This has unfortunately turned out to be quite the case,
as recent literature seems to indicate [13], [14]. As the
latter citation observes, the UBR concept has seen more
success in the form of private company registries.

A. RESTful Architecture
Coined by the famous Dr. Fielding (to whom all
of us who enjoy a highly performant Web are eternally
indebted) in his Doctoral dissertation [6], the REpresentational State Transfer (REST) architectural style has
proven to be the cornerstone of the Webs success at
scale.
A summary of the main principles that most of the
literature agrees with is given by [7]:
1)

2)
3)

also be manifested through the use of multiple

media types.
Requests on resources and responses must be
self-contained, i.e. stateless.
The flow of the system is primarily, if not
only, through navigation of hyperlinks found
in resource representations. Fielding referred
to this as Hypermedia As The Engine of
Application State (HATEOAS).

The central entity of a RESTful system is a

resource. Every resource also has a unique
identifier/address, standardized as the Uniform Resource Identifier (URI), within a
namespace.
All resources can be interacted with via a
standard uniform interface, through which the
state of a resource can be manipulated.
Resources are not accessed directly; rather, all
resources contain at least one representation,
which represents the state of the resource at the
time of access. Multiple representations can

The ProgrammableWeb is currently the most popular

centralized repository of listings of Web services, their

interfaces (API) and their descriptions. As mentioned

before, it is a directory which lists APIs as well as
mashups. It functions as a portal site where users can
register their APIs and mashups, manually search and
retrieve API descriptions, and view analytics on APIs
and mashups, such as popularity and usage patterns.
The literature critiques its minimalistic keyword and
category-based search functionality as well as the extra
manual effort required of end-users to sift through
API descriptions in order to consume services [11],
[15][17]. The ProgrammableWeb seems to function
similarly to the white/yellow/green pages style of UDDI
registries.

A. Web Service
The term Web Service has been defined at varying
levels of specificity throughout its time. Arguably the
most specific [2] definition is provided by Webopedia
[21] and is associated very tightly with the traditional
WS-* stack. A more generic one is provided as an
application whose operations can be accessed by other
applications over the Web [2]. We present our own definition of a service within the context of our framework:
A Web service (referred to in short as a service)
is defined as a modular piece of code which, like a
function, accepts certain input arguments, performs its
task based on the inputs, and accordingly produces the
output, if any. A service may call upon other services
to aid in performing its task.

C. Web Intents
Knowing that many diverse remote services are used
on a daily basis, it is quite ideal that web applications
would be able to seamlessly integrate with each other.
As documented above, this has proven to be quite a
challenge largely due to the difficulty of unifying/aggregating new services. In order to address this issue,
a framework for seamless client-side service discovery
and inter-application communication known as Web
Intents [18] was conceived. It is modelled after the
similarly-named system in the Android platform [19].

It can be seen that we have applied certain constraints to our definition of a service. Firstly, we detract
from the notion of a service as an entire self-contained
application consisting of various operations that form
a cohesive whole. Instead, we enforce a service to
focus on a single operation that it performs very well.
Such modularity encourages reuse and is a well-received
software engineering principle. One may observe that
focus on operations instead of applications hearkens
back to the low-level RPC-based middleware protocols.
However, RPC mechanisms are founded on distributed
shared state. This leads us to our next constraint, which
is the RESTful denunciation of maintaining application
state among queries. This is inspired by the functional
programming paradigm of avoiding state, mutable data
and side-effects. The latter is a little more nuanced and
will be touched on in sub-section D. Finally, the concept
of services invoking other services will be explained in
sub-section E.

The system involves three parties: Client, User

Agent and Service Provider. The Client is a user that is
in need of a particular service for its own workflow. It
registers this need with the Intents server via the User
Agent. This registration is expressed in the form of an
Intent, which is composed of an Action and a Type.
In advance, Service Providers register with the Intents
server and declare themselves capable of handling a
specific Action and Type. From these two parameters,
the server creates matches and provides a list of Service
Providers to the User Agent, which in turn presents
this list to the Client. The Client chooses the desired
Service Provider and the chosen Service Provider, then
performs the requested action. Input and output between
the Client/Service Provider is optional but in most cases
will exist.

B. Service as a Resource
In the Resource-Oriented Architecture paradigm, the
data that needs to be exposed via services is modelled
as the resource within the RESTful architecture. But
we face the interesting conundrum of the services themselves being the data that is being exposed to the public.
Thus, we refer to the Web services in our framework as
the resources. This model is key to enjoying the benefits
of REST. We discuss these specifics in the sub-sections
that follow.

Web Intents has unfortunately not enjoyed practical

use and the w3 specification that was being actively
developed has been halted and published as just an
informative Working Group Note as of May 23rd 2013
[20].
III.

C. Addressing Strategy

P ROPOSED F RAMEWORK

Every resource must be uniquely addressable via

a URI. In our framework, every service must be
accessible at a unique URI within its respective
namespace. This means that each service must have
a unique identifier within its namespace. For example,
a service which computes the sum of a sequence of
numbers may be identified as addnums. Assuming a
namespace of registries.com and the HTTP URI

Our framework serves as a response to the failure of

the UBR concept described in section 2. In particular,
we argue that an open collaborative registry of services
founded upon the architectural principles of REST is
a strong candidate for the fulfillment of the UBR concept, which we would informally modify as Universal
Service Registry (USR) in order to emphasize that the
scope goes beyond the enterprise world.

Since a fairly large number of services tend to

be pure, we naturally notice significant performance
improvements and better scalability.

scheme, the complete URI (to be precise, URL) may be

http://registries.com/services/addnums.
A resource can only be interacted with via its
representations, which must also be uniquely identified
(commonly referred to as endpoints). In the context
of our framework, the representations of a service can
be seen as the various output values that are returned
based on the provided input parameters3 . An important
observation on the definition of a function from a formal
perspective is that each element of the domain can
only map to one other element of the co-domain. Although the programming language concept of a function
generally varies from the mathematical definition, this
preliminary premise holds. Thus, we are guaranteed
unique addresses for each tuple of input parameters
for any given service. Continuing the example of the
addition service, let us assume that we have two cases:
1) compute the sum of 2 and 3, and 2) compute the sum
of 5, 6 and 7. The URLs4 would be:

E. Registration and Storage

An important feature of our framework is that service code will be stored directly in the registry as
opposed to a reference to an external URL. This enables
the enforcing of service standards and consequently
enhances trust levels.
F.

Search and Discovery

D. Cacheing

A key feature of REST is the HATEOAS principle.

Navigation in the standard document Web is driven by
this mechanism. To elaborate, whenever the representation of a resource is received, it more often than not
contains links to other resources. Upon selecting a link,
the representation for the selected resource is retrieved,
which in turm may contain links to other resources.
This gradual transitioning between application states as
opposed to providing access to all application states
at any given time is a consequence of the stateless
constraint of REST and is also another crucial factor
(apart from cacheing) for the scalability of the Web.

One of the best explanations for the inherent scalability of the RESTful architecture is its consequent
cacheing mechanism [7]. This has been applied successfully to the Web via the underlying HTTP protocol,
especially the Conditional GET feature [23] coupled
with the entity tag (ETag)5 . Cacheing is an extremely
important feature of our framework as it drastically
reduces the number of service invocations necessary.

We apply a similar perspective of HATEOAS to our

framework to facilitate the gradual discovery of services. Whenever the description of a service is queried,
it may contain links or advertisements to other services
in the registry. For example, the description of the
summation service used in the previous sub-sections
may contain links to related services such as services
for performing other arithmetic operations on numbers.

According to the principle of referential

transparency [24], an expression will always evaluate to the same value as long as it does not have
any side-effects. Such a function is commonly referred
to as a pure function, whereas the converse case is
known as an impure function. In other words, given a
specific tuple of input parameters, a pure function will
always return its corresponding value. Applying this to
our framework, services that can be classified as pure
functions can be cached via the HTTP Conditional GET
mechanism while impure function, such as services that
write to remote databases, are never cached. Continuing
the previous example, the representation of addnums
that computes thw sum of 2 and 3 will always be
5. Thus, the URL /services/addnums?num1=2&num2=3
can be cached.

G. Service Composition

1)
2)

/services/addnums?num1=2&num2=3
/services/addnums?num1=5&num2=6&num3=7

The creation of composite services is supported in

our framework via two constructs: 1) the Module system
and 2) Service-to-Service Consumption (S2SC)
1) Modules : We have already provided the definition of a service in sub-section A. We introduce a
slightly different type of a service known as a Module.
It is a service that cannot be consumed (invoked) but
serves as a helper or utility service that other services,
including other Modules, can build on. As such, the
only representations of Modules are their descriptions
and their raw code. This intentionally models the design
of local software libraries in order to encourage modular
development of services.
2) S2SC : Service-to-Service Consumption is the
application of the traditional concept of service composition to our constrained definition of Web services. It
is a feature that allows services to function as clients to
each other and perform invocations between each other.
This also encourages modular design. For example, a
service that implements the binary search algorithm may
invoke another service that performs sorting right before

3 We

found a very similar addressing strategy in [22], albeit it is

employed in the paper for a different purpose. Although we had
created our strategy long before running into this paper, it serves
as a fine example of scientific replication.
4 We have not included the namespace and the HTTP URI scheme
only for spatial concerns.
5 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html\#sec14.
19

it performs the binary search. Another benefit of this

construct is the interesting ability to form recursive invocation patterns. For example, a service that computes
the factorial of a given number may do so recursively
by consuming itself. For example, the factorial of 5 may
be retrieved via the URL /services/factorial?num=5,
which would multiply 5 by the factorial of 4 via
the URL /services/factorial?num=4, which would
multiply 4 by the factorial of 3 via the URL
/services/factorial?num=3, and so on and so forth.
While this may seem to be a significant overhead, such
a feature along with the encouragement of modular
services may increase opportunities for parallelization.
Additionally, the cacheing mechanism grants further
performance boosts to offset the initial overhead.
H. Uniform Interface
Each resource can only be interacted with via a small
number of standardized operations which are generally
the following6 : GET (retrieve a read-only representation), POST (perform a write operation on the resource,
PUT (replace the resource with the given data; another
write operation), DELETE (delete the resource). Our
framework applies these standard CRUD operations to
Web services in the registry. Briefly, GET is used to
obtain a description of the service or to retrieve the
return value given specific input parameters (service
invocation), PUT is used to register a new service, POST
may be used for service invocation when sensitive data
is transferred as the input parameters and DELETE is
used to delete a service.

Fig. 1: Overview of Framework. Arrows indicate requests

to the server. Although not shown due to spatial constraints,
it can be assumed that the server sends the corresponding
responses.

B. Platform
Our prototype is based on the NodeJS7 web platform on a Linux machine and consequently enjoys
its benefits. NodeJS employs a single-threaded eventdriven model for handling concurrent requests, as opposed to the more common multi-threaded approach.
Applications in NodeJS are built around handling events
that are emitted due to various triggers. These events
are handled via JavaScript callback functions which
are executed only when the event is actually triggered
and then caught. Until this takes place, the application
effectively sleeps. For example, a simple HTTP web
server can be designed to respond to incoming HTTP
requests from clients. When a client connects to the
server, an event is triggered and if it is designed to be
handled, the respective callback function is executed.
This simple design pattern actually exists throughout
the entire platform. In other words, almost every single
activity emits an event that can only be handled at a
later unspecified time by a callback function.

Figure 1 provides a simplified overview of the

framework in action. Note that the S2SC instance is
specially distinguished from the other regular Developer
interactions.
IV.

P ROTOTYPE I MPLEMENTATION

We have completed an initial iteration of a proofof-concept prototype implementation of our framework

in order to explore the feasibility thereof.
Every distributed system faces the innate challenges
of performance, scalability and reliability, and our prototype consequently is no different. This section briefly
describes some of our design decisions, the challenges
they addressed and how the prototype derives from our
framework.

As another example, reading a file on disk conventionally is a sequential operation that blocks a running
process, rendering it idle until the operation is complete.
On NodeJS, when a function is called to read a file,
it begins this activity, assigns the callback function (if
provided) and then immediately returns to the context.
When the file has been read, an event is triggered and
the provided callback function is executed. Note that
these callback functions themselves might perform other
activities which emit events that need to be handled
by callback functions, and so on and so forth. This

A. Programming Language Support

Although we ideally wish to support cross-language
interoperability, we decided to initially stick with one
language for simplicity. JavaScript was chosen due to
its maturity as a Web programming language as well
as support for full-stack development (elaborated in the
sub-section B).
6 A few other operations exist and are documented in the relevant
literature.

7 http://nodejs.org/about/

asynchronous non-blocking model is excellent for I/Ointensive applications as time spent waiting can be
utilized elsewhere. An analysis of our framework reveals
that HTTP requests and responses form the bulk of
operations throughout. As such, the evented singlethreaded model of NodeJS is a perfect fit.

such a system. As such, more emphasis was placed on

service invocation performance/scalability and programming abstractions for implementing new services, while
lesser emphasis was placed on search and discovery as
it is a comparitively much better-addressed problem in
the literature.

But the very same model has its drawbacks. NodeJS

is generally a poor candidate for CPU-intensive tasks.
We currently mitigate this by forking a child process
for each service that is invoked. As per [25], this costs
around 10 megabytes of memory for each new process.
Despite being a high cost, we believe that this is offset
by the reliability gains yielded by using Linux processes
instead of threads in our use-case. There is no need for
shared memory or fast context-switching as each service
code can be executed independently. Nonetheless, we
wish to experiment with using NodeJS only as an
efficient request gateway (where it excels) that proxies
service invocations to a multi-threaded environment.

V.

U SAGE S CENARIOS

In this section, a few of the many practical use cases

of implementing our framework are discussed.
A. Integrated Development Environments
A very practical example of an application of our
system is integration with software development environments or IDEs (Integrated Development Environment). Using such a tool, developers would be able to
incorporate different features into the applications that
they develop via a simple menu button which could
interface with the REST API of the registry. Developers could explore services that offer the exact/similar
functionality desired. If no suitable service exists, the
developer may choose to leverage existing services and
Modules to create a new service and register it via the
IDE. This composite service would now be available to
any other developer in the world.

Seeing that our system aims to open up to the entire

Web community of developers, we decided to implement our prototype on the Amazon Web Service (AWS)
cloud infrastructure8 . AWS grants users great freedom,
and consequently great responsibility, of customizing
their various infrastructure and platform services to
design highly scalable and reliable systems. Howeve,
we instantly benefit from the security and reliability of
the AWS infrastructure.

B. Mobile Code-Offloading
Our system may also be appealing to the mobile sector, where high power consumption, low computing resources and minimal improvements in battery efficiency
[27], [28] have given rise to interesting optimization
and micro-management problems. Mobile applications
that wish to take advantage of the functionality offered
by our participating services would simply invoke a
REST API that interfaces with the services by passing
input and receiving output. The processing of the data
is thus outsourced to these services that are external to
the mobile device, thereby preserving both battery and
computational resources. Note that this is in contrast
with attempts to partition code to execute both remotely
and locally. Instead, all computation would always be
performed remotely. While we see the clear advantage
of being able to focus all local resources on critical
tasks, some peers may disagree in preference of a
partitioning and optimization approach [29], [30].

C. Service Code Storage

We are currently using CouchDB9 for disk-based
permanent storage of registered services. It is a NoSQL
data store with eventual consistency, which means that
data is synchronized among nodes lazily, sacrificing
immediate consistency for vast gains in performance
[26]. Since participating services are not expected to
have a well-defined structure to their description, a nonrelational data store is a reasonable approach. CouchDB
uses a document-model where each database consists of
structured data known as documents that are stored as
JSON (JavaScript Object Notation) data. Document creation, modification, deletion, retrieval and many other
operations can all be performed via a REST API which
returns responses in JSON format. All the documents
of a database can also be aggregated and specially
queried to obtain meaningful information from them
using JavaScript view functions, which are equivalent to
standard map-reduce functionality. The technical benefits of the implementation, convenient accessibility via
a RESTful API and close integration with JavaScript
made CouchDB a very valid choice for our prototype.

VI.

C ONCLUSION AND F UTURE W ORK

We have presented in this paper a framework for a

scalable community of modular functional services that
is open to any developer for both service contribution/composition and consumption. We also presented our
initial proof-of-concept prototype implementation. We
are currently in the process of performing performance
and scalability evaluation in order to empirically guage
the feasibility of our framework.

Finally, we wish to clarify that our prototype does

not yet implement all components of our framework.
Our focus is currently on the runtime feasibility of
8 http://aws.amazon.com/
9 http://couchdb.apache.org/

By no means do we consider our work complete.

Many interesting problems that were out of the scope
of our work remain open to research. We list some of
them below:

[13]

[14]

Exploring the Semantic Web and leveraging it

in our framework in order to enhance the search
and discovery process.

[15]

Enabling
cross-language
interoperability.
Specifically, allowing developers to contribute
services written in any language of their
choice.

[16]

Investigating the application of the HATEOAS

principle to automated service composition and
invocation, as per the interesting work of [31].

[17]

Creating strategies for addressing potential conflicts with source code licensing.

[18]

Implementing processes for evaluating both

functional and non-functional QoS metrics. Particularly, determining if a particular service has
been implemented correctly is a very interesting
problem.

[19]

[20]

R EFERENCES
[1]
[2]
[3]

[4]

[5]

[6]

[7]

[8]
[9]

[10]

[11]

[12]

[21]

C. Ferris and J. Farrell, What are web services? Communications of the ACM, vol. 46, no. 6, p. 31, 2003.
G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web services:
concepts, architectures and applications. Springer, 2004.
A. Koschmider, E. Wilde, and C. Zirpins, 5th international
workshop on web apis and service mashups (mashups 2011):
introduction by the workshop chairs, in Proceedings of the
5th International Workshop on Web APIs and Service Mashups.
ACM, 2011, p. 1.
ProgrammableWeb - Mashups, APIs, and the Web as Platform, http://www.programmableweb.com/, retrieved on July
7th 2013.
briandoll, The Octoverse in 2012, https://www.github.com/
blog/1359-the-octoverse-in-2012, 2012, retrieved on May 30th
2013.
R. T. Fielding, Architectural styles and the design of networkbased software architectures, Ph.D. dissertation, University of
California, 2000.
C. Davis, What if the web were not restful? in Proceedings
of the Third International Workshop on RESTful Design, ser.
WS-REST 12. New York, NY, USA: ACM, 2012, pp. 310.
L. Richardson and S. Ruby, RESTful web services. OReilly,
2008.
E. Al-Masri and Q. H. Mahmoud, Wsce: A crawler engine for
large-scale discovery of web services, in Web Services, 2007.
ICWS 2007. IEEE International Conference on. IEEE, 2007,
pp. 11041111.
M. Maleshkova, C. Pedrinaci, and J. Domingue, Investigating
web apis on the world wide web, in Web Services (ECOWS),
2010 IEEE 8th European Conference on. IEEE, 2010, pp.
107114.
Y.-J. Lee and J.-H. Kim, Semantically enabled data mashups
using ontology learning method for web apis, in Computing,
Communications and Applications Conference (ComComAp),
2012. IEEE, 2012, pp. 304309.
B. Sleeper, The evolution of uddi, UDDI. org White Paper,
The Stencil Group, Inc, pp. 115, 2002.

[22]

[23]
[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

M. Lanthaler and C. Gutl, Towards a restful service ecosystem, in Digital Ecosystems and Technologies (DEST), 2010
4th IEEE International Conference on. IEEE, April 2010, pp.
209214.
T. Pilioura and A. Tsalgatidou, Unified publication and discovery of semantic web services, ACM Trans. Web, vol. 3,
no. 3, pp. 11:111:44, Jul. 2009.
R. Verborgh, S. Coppens, T. Steiner, J. G. Valles,
D. Van Deursen, and R. Van de Walle, Functional descriptions
as the bridge between hypermedia apis and the semantic web,
in Proceedings of the Third International Workshop on RESTful
Design. ACM, 2012, pp. 3340.
K. Gomadam, A. Ranabahu, M. Nagarajan, A. P. Sheth, and
K. Verma, A faceted classification based approach to search
and rank web apis, in Web Services, 2008. ICWS08. IEEE
International Conference on. IEEE, 2008, pp. 177184.
Y.-J. Lee and J.-S. Kim, Automatic web api composition for
semantic data mashups, in Computational Intelligence and
Communication Networks (CICN), 2012 Fourth International
Conference on. IEEE, 2012, pp. 953957.
Web Intents, http://www.webintents.org/#introduction, retrieved on June 25th 2013.
P. Kinlan, PaulKinlan/WebIntents GitHub, https://github.
com/PaulKinlan/WebIntents#web-intents, 2012, retrieved on
June 25th 2013.
G. Billock, J. Hawkins, and P. Kinlan, Web Intents, http:
//www.w3.org/TR/web-intents/, 2013, retrieved on December
16th 2013.
Web Services, http://www.webopedia.com/TERM/W/Web
Services.html, retrieved on April 3rd 2014.
L. Bao, Q. Li, K. Zhen, W. Xiang, and P. Chen, A functional
flavor of service composition, in Fuzzy Systems and Knowledge Discovery (FSKD), 2011 Eighth International Conference
on, vol. 4, July 2011, pp. 23442348.
J. Kurose and K. Ross, Computer networking: a top-down
approach. Addison-Wesley, Pearson Education Inc., 2010.
R. M. Keller and M. R. Sleep, Applicative caching, ACM
Trans. Program. Lang. Syst., vol. 8, no. 1, pp. 88108, Jan.
1986.
Child process, http://nodejs.org/api/child process.html#
child process child process fork modulepath args options,
retrieved on April 4th 2014.
Eventual Consistency; Apache CouchDB 1.6 Ddocumentation, http://docs.couchdb.org/en/latest/intro/consistency.html,
retrieved on December 17th 2013.
E. Cuervo, A. Balasubramanian, D. Cho, A. Wolman, S. Saroiu,
R. Chandra, and P. Bahl, Maui: Making smartphones last
longer with code offload, in Proceedings of the 8th international conference on Mobile systems, applications, and
services, ser.
MobiSys 10. New York, NY, USA: ACM, 2010, pp. 4962.
N. Fernando, S. W. Loke, and W. Rahayu, Mobile cloud
computing: A survey, Future Generation Computer Systems,
vol. 29, no. 1, pp. 84106, 2012.
B.-G. Chun and P. Maniatis, Dynamically partitioning applications between weak devices and clouds, in Proceedings of the
1st ACM Workshop on Mobile Cloud Computing #38; Services:
Social Networks and Beyond, ser. MCS 10. New York, NY,
USA: ACM, 2010, pp. 7:17:5.
R. Kemp, N. Palmer, T. Kielmann, and H. Bal, Cuckoo: a
computation offloading framework for smartphones, Mobile
Computing, Applications, and Services, pp. 5979, 2012.
S. Parastatidis, J. Webber, G. Silveira, and I. S. Robinson,
The role of hypermedia in distributed system development,
in Proceedings of the First International Workshop on RESTful
Design, ser. WS-REST 10. New York, NY, USA: ACM, 2010,
pp. 1622.