Conference PaperPDF Available

EMF-REST: generation of RESTful APIs from models



In the last years, there has been an increasing interest for Model-Driven Engineering (MDE) solutions in the Web. Web-based modeling solutions can leverage on better support for distributed management (i.e., the Cloud) and collaboration. However, current modeling environments and frameworks are usually restricted to desktop-based scenarios and therefore their capabilities to move to the Web are still very limited. In this paper we present an approach to generate Web APIs out of models, thus paving the way for managing models and collaborating on them online. The approach, called EMF-REST, takes Eclipse Modeling Framework (EMF) data models as input and generates Web APIs following the REST principles and relying on well-known libraries and standards, thus facilitating its comprehension and maintainability. Also, EMF-REST integrates model and Web-specific features to provide model validation and security capabilities, respectively, to the generated API.
EMF-REST: Generation of RESTful APIs from Models
Hamza Ed-douibi, Javier Luis Cánovas Izquierdo, Abel Gómez,
Massimo Tisi, Jordi Cabot
AtlanMod team (Inria, Mines Nantes, LINA), Nantes, France
Abstract. In the last years, RESTful Web services have become more and more
popular as a lightweight solution to connect remote systems in distributed and
Cloud-based architectures. However, being an architectural style rather than a
specification or standard, the proper design of RESTful Web services is not triv-
ial since developers have to deal with a plethora of recommendations and best
Model-Driven Engineering (MDE) emphasizes the use of models and model trans-
formations to raise the level of abstraction and semi-automate the development
of software. In this paper we present an approach that leverages on MDE tech-
niques to generate RESTful services. The approach, called EMF-REST, takes
EMF data models as input and generates Web APIs following the REST princi-
ples and relying on well-known libraries and standards, thus facilitating its com-
prehension and maintainability. Additionally, EMF-REST integrates model and
Web-specific features to provide model validation and security capabilities, re-
spectively, to the generated API. For Web developers, our approach brings more
agility to the Web development process by providing ready-to-run-and-test Web
APIs out of data models. Also, our approach provides MDE practitioners the ba-
sis to develop Cloud-based modeling solutions as well as enhanced collaborative
1 Introduction
Web services have increasingly become popular mainly because they simplify clien-
t/server decoupling and foster interoperability. In the last years, the emergence of dis-
tributed architectures, specially Cloud-based ones, and mobile devices have also pro-
moted the development of lightweight applications over portable devices, which rely on
web Services rather than on heavyweight desktop-based solutions.
Among the different standards for designing distributed services (e.g., SOAP, WSDL
or WS-* specifications), there is a rising trend to use lightweight solutions based on
plain HTTP referred to as REpresentational State Transfer (REST) [11] services. REST
proposes the development of stateless distributed services and relies on simple URIs
and HTTP verbs to make the Web services broadly available for a number of front-end
devices. However, REST is rather an architectural style than a standard, therefore of-
fering a considerable design and implementation flexibility. This is in theory a good
thing but it can quickly lead to bad designs and architectures that end up not being con-
formant with the REST principles [19]. Thus, developing high-quality REST APIs for
non-trivial applications may become a hard and time-consuming task.
On the other hand, Model-Driven Engineering (MDE) is a paradigm which em-
phasizes the use of models to raise the level of abstraction and automation in the de-
velopment of software. By working at a high level of abstraction, we believe that the
application of MDE to the Web environment offers important benefits in development,
consistency and definition of concepts. For instance, MDE methodologies have been ap-
plied to bring more agility to the development of distributed applications by addressing
the different aspects of Web development.
As a way to combine the benefits of both domains, in this paper we propose EMF-
REST, an approach that leverages on MDE techniques to generate RESTful Web APIs
out of plain data models. The generated RESTful Web API relies on well-known li-
braries and standards with the aim of facilitating its understanding and maintainability.
Unlike other existing MDE-based approaches targeting the generation of Web services,
ours provides a direct mapping to access data models by means of Web services fol-
lowing the REST principles, thus liberating Web developers from parameterizing the
generation process or explicitly modeling the API to be generated. Additionally, EMF-
REST takes advantage of model and Web-specific features such as model validation
and security, respectively, thus providing the corresponding support in the resulting
RESTful Web API. We aim to target two main communities with EMF-REST. For Web
engineers, EMF-REST brings more agility to the Web development process by provid-
ing ready-to-run-and-test Web APIs out of data models. For MDE practitioners, our
approach provides the basis to develop model-based solutions relying on the Cloud as
well as an enhanced collaborative support for Web-based modeling tools. In this paper
we will mainly focus on the first group of users.
The remainder of this paper is structured as follows. Section 2 presents some back-
ground of REST and MDE. Section 3 describes how we devised the mapping between
EMF and REST principles, while Section 4 describes the additional EMF-REST fea-
tures. Section 5 presents the technical architecture of the generated REST API. Section
6 describes the steps we followed to generate the API. Section 7 presents the possible
applications of our approach. Section 8 discusses some related work. Finally, Section 9
concludes the paper and presents the future work.
2 Background
2.1 REST principles
In 2000, Roy Fielding identified specific design principles that led to the architectural
style known as REpresentational State Transfer (REST) [11]. By relying on the HTTP
protocol, this architectural style consists of several constraints to address separation of
concerns, visibility, reliability, scalability and performance. REST principles are de-
fined as:
Addressable resources Each resource must be addressable via a Uniform Resource
Identifier (URI).
Representation-oriented A resource referred by one URI may have different repre-
sentation formats (e.g., JSON, XML, etc.).
Statelessness Servers cannot hold the state of a client session. Instead, data represen-
tation formats provide information on how to manage the state of the application
for each client (e.g., using embedded URIs).
Uniform and Constrained Interface A small set of well-defined methods are used to
manipulate resources (i.e., HTTP verbs).
The last two principles are maybe the most distinguishing features of REST from
other Web services specifications. According to these principles, each request is treated
as an independent transaction and must only rely on the set of operations of the HTTP
protocol. HTTP methods are used in REST as follows:
GET Used to retrieve a representation of a resource. It is a read-only, idempotent and
safe operation.
PUT Used to update a reference to a resource on the server and it is idempotent as well.
POST Used to create a resource on the server based on the data included in the body
request. It is the only nonidempotent and unsafe operation of HTTP.
DELETE Used to remove a resource on the server. It is idempotent as well.
HEAD Similar to GET but returning only a response code and the header associated
with the request.
OPTIONS Used to request information about the communication options of the ad-
dressed resource (e.g., security capabilities such as CORS).
Being a collection of principles rather than a set of standards, several resources on
best practices and recommendations were written to help developers to write RESTful
Web services. In order to generate a high-quality RESTful Web API, we apply in EMF-
REST the best practices described in [19].
2.2 The MDE paradigm
The MDE paradigm emphasizes the use of models to raise the level of abstraction and to
automate the development of software. Abstraction is a primary technique to cope with
complexity, whereas automation is the most effective method for boosting productivity
and quality [25].
Modeling languages express models at different abstraction levels, and are defined
by applying metamodeling techniques [7]. In a nutshell, models are defined according to
the semantics of a model for specifying models, also called a metamodel. A model that
respects the semantics defined by a metamodel is said to conform to/to be an instance
of such a metamodel.
The Eclipse Modeling Framework (EMF) [2] has become the main reference for
modeling in Eclipse [10]. Among its features, EMF allows creating metamodels – by
using the Ecore language, a subset of the UML class diagrams – and their instances.
Along this paper, we refer to metamodels as Ecore models, and their instances as model
instances. Ecore can be considered as an implementation of MOF [20], a modeling and
metamodeling standard developed by the Object Management Group (OMG). Addition-
ally, EMF provides a generative solution which constructs Java APIs out of those mod-
els to facilitate their management, thus promoting the development of domain-specific
address : String
name : String
breed : String
Dog Cat
RaceDog HuntingDog
firstName : String
lastName : String
family 1sons
Fig. 1. Simple Family Ecore Model.
On the other hand, model transformations generate software artifacts from models,
either directly by model-to-text transformations (e.g., using languages such as Acceleo
or Xpand) or indirectly by intermediate model-to-model transformations (e.g., using
languages such as ATL or ETL)1. By means of modeling languages and model transfor-
mations, it is possible to increase both the level of abstraction and provide automation
in MDE, respectively.
3 Mapping EMF and REST principles
The first step to build EMF-REST is to align the principles behind the MDE/EMF
and REST worlds. EMF-REST relies on EMF to represent the models from which the
RESTful Web APIs are generated. As EMF models and their instances are managed
by the corresponding APIs provided by the framework (i.e., Ecore and EObject APIs,
respectively), we need to define a mapping between such APIs and the REST princi-
ples presented before. In this section we explain how we map EMF with each REST
To illustrate the alignment, we will use a running example consiting in the creation
of a distributed application aimed at managing information about families (e.g., parents,
children, pets, etc.). Figure 1 represents a possible Ecore model for this example. As can
be seen, the Family concept includes one attribute (i.e., address) to represent the address
of the family and references the members (i.e., Member hierarchy, including Parents,
Sons and Daughters) and pets (i.e., Pet concept) of the family. Additionally, different
types of pets are allowed (i.e., Cat and Dog concepts plus RaceDog and HuntingDog
for dog types). Figure 2 shows an intantiation of this family model for the specific case
of the Simpsons family.
In what follows we will see how EMF-REST would allow to create the Simpons
family by calling a REST API generated from the Family model following the REST
3.1 Addressable Resources
Models in EMF are addressed via a URI, which is a string with a well-defined structure
as shown in the expression (1). This expression contains three parts specifying: (1) a
scheme, (2) a scheme-specific part and (3) an optional fragment. The scheme is the first
1Acceleo, XPand, ATL and ETL can be found at
Simpsons : Family
address : ’742 Evergreen Terrace’
Homer : Parent
firstName : ’Homer’
lastName : ’Simpson’
Marge : Parent
firstName : ’Marge’
lastName : ’Bouvier’
Bart : Son
firstName : ’Bart’
lastName : ’Simpson’
Lisa : Daughter
firstName : ’Lisa’
lastName : ’Simpson’
Maggie : Daughter
firstName : ’Maggie’
lastName : ’Simpson’
Santa : RaceDog
breed : ’Greyhound’
name : ’Santa’s Little Helper’
SnowBall : Cat
breed : ’Unknown’
name : ’Snowball II’
parents parents sons daughters daughters
Fig. 2. The Simpsons Family.
part separated by the ":" character and identifies the protocol used to access the model
(e.g., platform,file or jar). In Eclipse we use platform for URIs that identify resources
in Eclipse-specific locations, such as the workspace. The scheme-specific part is in the
middle and its format depends on the scheme. It usually includes an authority that
specifies a host, the device and the segments, where the latter two constitute a local path
to a resource location. The optional fragment is separated from the rest of the URI by
the #character and identifies a subset of the contents of the resource specified by URI,
as we will ilustrate below. The expression (2) shows an example of a platform-specific
URI which refers to the Simpsons family model, represented as a file Simpsons.xmi
contained in a project called project in Eclipse workspace. It is important to note that in
EMF model instances include a reference to the Ecore model they conform to.
[scheme:][scheme-specific-part][#fragment] (1)
platform:/resource/project/Simpsons.xmi (2)
EMF-REST maps the previous URI to a Web URL as follows. The base URL pattern
of a model instance is defined by the expression (3). In the pattern, the part https://
[applicationLink]/rest is the URL of the Web application, modelId is the identifier of
the model (e.i., the Ecore model) and ModelInstanceId is the identifier of the model
instance being accessed (the XMI file). The URL (4) represents an example to retrieve
the Simpsons family. As can be seen, while the URI can address a file representing a
model instance (where a reference to the Ecore model is included), the URL requires
indicating the identifier of both the Ecore model and the model instance.
https://[applicationLink]/rest/[ModelId]/[ModelInstanceId] (3) (4)
This URL acts as the entrypoint for a particular model instance and points to its root
element, which is normally the case in EMF. When the model instance has more that
one root, EMF-REST points at the first.
Once pointing to the root of a model instance, addressing a particular element of the
model in the EMF API is done by using the part fragment in (1). The navigation is done
using the reference names in the Ecore model. For instance, the concept Family has the
reference parents to access to the list of parents. Using the EMF API, the URI is shown
in (5), while using the Web API, the URL is shown in (6).
platform:/resource/project/Simpsons.xmi#//@parents (5) (6)
Depending on the cardinality of the reference this will return a specific element – if it
single-valued – or a collection of elements – if it is multi-valued (like in the case of
parents). Accessing a specific element contained in a collection can be done using (i)
the identifier of the element or (ii) its index in the list. For instance, the URI (7) retrieves
the element representing Homer in EMF, while in EMF-REST it is done using the call
(8). To identify an element, EMF-REST relies on the identifier flag provided by Ecore,
which allows setting the attribute acting as identifier for a given class2.
platform:/resource/project/Simpsons.xmi#Homer (7) (8)
On the other hand, the call (9) will retrieve the first element of the collection of parents
in the EMF API. In EMF-REST, it is done by adding the parameter index in the URL
as illustrated in the call (10).
platform:/resource/project/Simpsons.xmi#//@parents.0 (9) (10)
3.2 Representation-Oriented
By default, EMF persists models using the XMI representation format. EMF-REST
offers the same XMI option but also a JSON-based storage in order to comply with the
representation-oriented principle of the REST architecture.
For the JSON, EMF-REST adheres to the following structure. Model concepts are
represented as JSON objects containing key/value pairs for the model attributes/refer-
ences. Keys are the name of the attribute/reference of the concept and values are their
textual representation in one of the datatypes supported in JSON (i.e., string, boolean,
numeric, or array). For attributes, their values are mapped according to the correspond-
ing JSON supported datatype or String when there is not a direct correspondence (e.g.,
float-typed attributes). When the attribute is multi-valued, its values are represented us-
ing the array datatype. For references, the value is the URI of the addressed resource
within the server (if the reference is multi-valued, the value will be represented as an
array of URIs). Listing 1 shows an example of the content format in JSON. Note that
references containing a set of elements from model hierarchies are serialized as a list of
JSON objects corresponding to their dynamic type (see pets reference including Race-
Dog and Cat JSON objects).
In XML, model concepts are represented as XML elements including an XML ele-
ment for each model attribute/reference. Attribute values are included as string values
2When the identifier flag is not used, the fallback behavior looks for an attribute called id,
name or having the unique flag activated.
Listing 1. Partial JSON representation of the Simpsons family.
3"address":"742 Evergreen Terrace",
10 "raceDog":{"uri":"’s
Little Helper"},
11 "cat":{"uri":" II"}
12 }
13 ...
14 }
15 }
Listing 2. Partial XML representation of the the Simpsons family.
2<address>742 Evergreen Terrace</address>
10 </parents>
11 <pets>
12 <raceDog>
13 <uri>’s Little Helper
14 </raceDog>
15 <cat>
16 <uri> II</uri>
17 </cat>
18 </pets>
19 ...
20 </family>
in the XML element representing such attribute, references are represented according
to their cardinality. If the reference is single-valued, the resulting XML element will
include only the URI of the addressed resource in the server. On the other hand, if the
reference is multi-valued, the resulting XML element will include a set of XML ele-
ments including the URIs addressing the resources. Listing 2 shows an example of the
content format in XML format.
3.3 Uniform and Constrained Interface & Statelessness
EMF supports loading, unloading and saving model instances after their manipulation.
In EMF-REST, these operations are managed by the application server. Models are
loaded (and unloaded) dynamically as resources when running the application manag-
ing the Web API, and they are saved after each operation is done, thus conforming to
the REST statelessness behavior.
Listing 3. Update the attribute of a concept using EMF generated API.
2hommerObj.setName("Homero"); // hommerObj is of type Parent
Listing 4. HTTP call and JSON representation to update the firstname of the addressed parent.
Table 1. Supported operations in the generated API.
CREATE and add element to the collection POST .../a/bs
bs 0..* c0..1
READ all the elements from the collection GET
READ the element
(1) identified by <id>,
(2) in the <i> position of the collection, or
(3) the element c
UPDATE the element
(1) identified by <id>,
(2) in the <i> position of the collection, or
(3) the element c
(1) .../a/bs/<id>
(2) .../a/bs?index=<i>
(3) .../a/c
DELETE the element
(1) identified by <id>,
(2) in the <i> position of the collection, or
(3) the element c
To manipulate model instances, EMF enables the basic CRUD (i.e., create, read,
update and delete) operations over model instances by means of either the EMF gener-
ated API or the EObject API. In EMF-REST, the same CRUD operations are mapped
into the corresponding HTTP methods (POST,GET,PUT, and DELETE). For instance,
Listing 3 shows the code to modify the name of the parent called Homer using EMF
generated API for the Family model. The same operation can be done on our EMF-
REST API by sending the PUT HTTP method containing the JSON representation of
the new Parent model element, as shown in Listing 4.
Table 1 shows how each CRUD operation is addressed along with several URL
examples. The first column of the table describes the operations. As can be seen, the
first two rows represent operations over collections, enabling adding new elements (see
first row) and reading their content (see second row). The rest of the rows describe
operations over either individual elements of a collection (see cases 1 and 2 of these
operations) or elements contained in a single-valued reference (see case 3). The second
column shows the correspondent HTTP method for each operation while the third col-
umn presents the corresponding URL for each case. Finally, the last column includes a
small model to better illustrate the cases considered in the table.
Fig. 3. Annotations on an excerpt of the example model.
4 Additional EMF-REST Features
EMF-REST also provides support for validation and security aspects in the generated
RESTful Web API. With this aim, our approach leverages on model and Web-specific
mechanisms, as we will describe below.
4.1 Validation
Validation is the process of verifying that the given data inputs respect the defined con-
straints at the model level Support for validating the API data calls is pretty limited in
current web technologies. The most relevant one for our scenario would be the Bean
Validation specification that defines an API to enforce the validation of Java Beans.
However, this specification can only ensure that fields follow certain constraints (e.g., a
field is not null) and cannot satisfy complex validation scenarios for model integrity
(e.g., a son cannot have more than two parents). On the other hand, MDE provides spe-
cific support for validating models, for instance, by providing an implementation (both
IDE support and run-time engine) the Object Constraint Language [26], a language
complementing UML [23] that allows software developers to write complex constraints
over object models. Thus, for validation, EMF-REST employs a model-based approach
using OCL to define constraints as annotations in the model elements.
OCL annotations can be attached to concepts in the model as invariants. An example
on the Simpsons family is shown in Figure 3. As can be seen, concepts include a set of
invariants inside the annotation OCL plus the annotation Ecore/constrains which spec-
ifies the invariants to execute. Invariants are checked each time a resource is modified
(i.e., each time the Web API is called from a Web-based client using the POST,PUT
or DELETE methods). This validation scheme is imposed to comply with the stateless
property of REST architetures, however, it may involve some design constraints when
creating the model. In those cases where models cannot be validated each time they
are modified (e.g., creating model elements requires several steps to fulfill cardinality
constraints), EMF-REST allows this validation process to be temporary be deactivated.
The results of the validation process are mapped into the corresponding HTTP response
messages (i.e., using status codes)
4.2 Security
Security is one of the cornerstones when developing Web-enabled applications. In this
case, there is little support for security definition and enforcement from the MDE side
since most tools just execute on a local environment but we have plenty of support from
web technologies to add security aspects to our generated API and protect the access to
the data models. In particular, our approach allows designers to provide some security
annotations on the model that are then translated into security restrictions as described
below. As part of the generation, EMF-REST also creates a separated admin view where
additional security information (like users and passwords) can be maintained.
In order to secure a Web application, we have to: (i) ensure that only authenti-
cated users can access resources, (ii) ensure the confidentiality and integrity of data
exchanged by the client and the server from the moment of sending a request to the mo-
ment of receiving a response, and (iii) prevent unauthorized clients from abusing data.
In order to address the previous requirements, EMF-REST relies on a set of security
protocols and services provided by Java EE which enable encryption, authentication
and authorization in Web APIs, as we will explain in the following.
Encryption If the connection is not secured, it is possible to intercept the packets and
collect sensitive data when interacting with a Web API. Encrypting the information ex-
changed between the client and server makes it only readable by the destination holding
the decryption key. The Web defines HTTPS protocol to add the encryption capacities
of SSL/TLS to standard HTTP communication. EMF-REST enforces the use to HTTPS
to communicate with its services.
Authentication Authentication is about validating the identity of a client attempting
to access a resource on a server. The validation process checks if the client has pro-
vided valid credentials and can be performed using several protocols, namely: basic
authentication, digest authentication and X.509 certificates. EMF-REST relies on ba-
sic authentication to provide the authentication mechanism since it is simple, widely
supported, and secure by using HTTPS. The basic authentication involves sending
a Base64-encoded username and password within the HTTPS request header to the
server. Upon reception, the server checks the credentials and send a response contain-
ing the requested data if credentials are correct or an unauthorized response otherwise.
Authorization The role of authorization is to define if the user has the permission to
access a resource. Authorization is usually combined with authentication to identify
users and determine which type operation is allowed for each one of them. While the
authentication is enabled by the protocol/server, the authorization is generally provided
by the application, which knows the permissions for each operation in the resources.
EMF-REST uses a simple role-based mechanism to support authorization in the gener-
ated Web API. Roles are associated to users (i.e., authentication) and operations in the
Web API (i.e., authorization). In EMF-REST roles are assigned to resources by adding
annotations to the model. Figure 3 illustrates the use of these annotations (e.g., see an-
notation Ecore/roles in the Member concept). Additionally, EMF-REST also provides
an admin view to create users and assigns one or more roles to each user, as we will
show in section 5.3.
  
   
 !
Fig. 4. Architecture of EMF-REST generated application.
5 EMF-REST API Architecture
To implement the features described in the previous sections, we devised the application
architecture presented in Figure 4. This architecture can then be seamlessly accessed
with a variety of clients.
The Web application is split into three main components according to the func-
tionality they provide: (1) content management, (2) validation and (3) security. The
application relies on EMF as modeling framework and uses the following additional
frameworks/specifications for each component, respectively: (1) Java Architecture for
XML Binding (JAXB) to enable the content format support, (2) Eclipse OCL frame-
work to provide validation before updating the model, (3) Java Persistence API (JPA)
to provide security support by storing the system users and their permissions in an em-
bedded database. The Web application also leverages on Enterprise Java Bean (EJB),
Context dependency Injection (CDI) and Java API for Representational State Transfer
(JAX-RS) specifications. EJBs enable rapid and simplified development of distributed,
transactional, secure and portable applications. They are in charge of loading the EMF
resources from the persistent storage and providing the necessary methods to manage
the resources (e.g., obtaining objects from the resource, removing objects) in a secure
and transactional way. These EJBs are then injected into JAX-RS services using CDI
technology. Thus, JAX-RS is used to expose EMF resources as Web services. In the
remaining of the section we describe how all these technologies are used in each com-
5.1 Content Management
This component addresses the mapping between EMF and REST principles. It is in turn
split into two subcomponents: (1) content format, which addresses the mapping of the
second REST principle (i.e., Representation-Oriented); and (2) navigation/operation,
which addresses the rest of the REST principles.
Regarding the content format, EMF-REST enriches the EMF-generated API with
JAXB3annotations, which enable the support for mapping Java classes to XML/J-
Listing 5. Part of the Family concept.
1@XmlRootElement (name="family")
2public class FamilyImpl extends EObjectImpl implements Family {
4protected EString address;
5protected EList<Parent> parents;
7@XmlElementWrapper(name = "parents")
10 public EList<Parent> getParents() {
11 if (parents == null) {
12 parents = new EObjectContainmentWithInverseEList<Parent>(Parent.
class,this, ExamplePackage.FAMILY__PARENTS, ExamplePackage.
13 }
14 return parents;
15 }
17 @XmlElementWrapper(name = "pets")
18 @XmlJavaTypeAdapter(PetAdapter.class)
19 @XmlAnyElement(lax=true)
20 public EList<Pet> getPets() {
21 if (pets == null) {
22 pets = new EObjectContainmentEList<Pet>(Pet.class,this,
23 ExamplePackage.FAMILY__PETS);
24 }
25 return pets;
26 }
28 @XmlElement
29 public String getAddress() {
30 return address;
31 }
32 ...
34 }
SON (i.e., marshalling/unmarshalling Java object into/from XML/JSON documents).
The Listing 5 shows an example of the use of JAXB annotations to produce the cor-
responding representation in JSON (as shown in Listing 1) and XML ((as shown in
Listing 2). As can be seen, each concept class is mapped to an XmlRootElement
element, while either XmlElement or XmlElementWrapper elements are used to
map the attributes or references of the class, respectively. Other annotations are used
to deal with the references and inheritance. For instance, XmlJavaTypeAdapter is
used to associate a reference of an element with the correspondent representation.
Navigation and operations are enabled by using JAX-RS, which provides a set of
Java APIs for building Web services conforming to the REST style. Thus, this specifica-
tion defines how to expose POJOs as Web resources, using HTTP as network protocol.
For each concept (e.g., Family) a resource will be created (e.g., FamilyResource)
annotated with Path (e.g., @Path("Family")). The @Path annotation has the
value that represents the relative root URI of the addressed resource. For instance, if
the base URI of the server is, the resource will be
available under the location To produce
a particular response when a request with GET, PUT, POST and DELETE is inter-
cepted by a resource, resource methods are annotated with @GET,@PUT,@POST and
@DELETE what are invoked for each corresponding HTTP verb.
5.2 Validation
EMF-REST leverages on Eclipse OCL4, which provides an implementation of the OCL
OMG standard for EMF-based models, to validate the data by means of annotations
including the constrains to check the model elements. The generated API relies on the
provided APIs for parsing and evaluating OCL constraints and queries on Ecore models.
When constraints are not satisfied, the validation process will fire an exception that will
be mapped by JAX-RS into an HTTP response including the corresponding message
indicating the violated constraint.
5.3 Security
EMF-REST relies on the combination of Java EE and JAX-RS for the authentica-
tion and authorization mechanisms by using the concept of role, while encryiption
is provided by using HTTPS. To enable authentication, the deployment descriptor of
the WAR file (i.e., WEB-INF/web.xml) has been modified to include the security
constraints (i.e., <security-constraint>) defining the access privileges. As-
signing permissions for HTTP operations based on the roles provided in the model
is done by using the @RolesAllowed annotation. For example, as shown before,
Figure 3 shows that the role allowed for the Member concept is admin. This will re-
strict access to the resource to the users having the role ADMIN. To express this in the
generated API, the annotation @RolesAllowed({"ADMIN"}) is placed on top of
MemberResource. If no role is assigned to a concept, a @PermitAll annotation
is placed on the resource class meaning that all security roles are permitted to access
this resource. Note that security roles assigned to a resource are not inherited by its
To manage the list of users and their roles, EMF-REST generates an admin view
that allows the manager of the API to add, edit and remove users. All created users have
a default role (i.e., user) allowing them to access unannotated concepts. The manager
can assign more roles to a user in order to grant him/her access to a specific resource.
6 Code Generation and Tool Support
In order to generate the REST APIs we created a Java tool available as an open-source
Eclipse plugin [1]. Figure 5 shows the steps followed by the tool to generate the appli-
cation starting from an initial Ecore model.
Step I of the process generates a Maven-based 5project that serves as a skeleton of
the application. Maven allows a project to be built by using the so called Project Object
Model (POM) file, thus providing a uniform build system. The POM is initialized with
the required library dependencies described in the previous section.
 (0)-DYD$3,
 -$;%
D E
Fig. 5. EMF-REST generation process.
In Step II, the EMF code generation facility has been extended to include the re-
quired support for JAXB and validation. In particular, the EMF generator templates
have been extended to produce the code corresponding to the JAXB annotations and
the required methods to execute the OCL validation process.
Step III performs a set of model-to-text transformations using the ETL6language
to generate the remaining elements, including: (1) the JAX-RS, CDI and EJB imple-
mentation classes, (2) the admin view developed and (3) a simple JavaScript API to
facilitate Web developers to build clients for the generated Web API. For each part
of the application (e.g., JAX-RS resources, etc.), an ETL transformation template has
been implemented to generate the appropriate behavior according the input Ecore class.
Since this step requires several transformations, the MTC tool [5] has been used to
orchestrate the flow of the Epsilon templates.
7 Applications
In this section we discuss potential applications of EMF-REST. The first section covers
the main scenario targeting EMF-REST illustrating how our approach can help web
developers to quickly create/prototype web services, while the second section illustrates
how EMF-REST can set the basis for promoting scalability and collaboration in MDE.
7.1 Generation of Web Services
To develop a REST API for a data model, web developers have to implement a middle-
ware framework supporting the REST access to the model elements and, additionally,
develop the extra support to cover a number of typically required features such as se-
curity, persistence or validation. Thus, the development process requires a considerable
effort, not only to implement the services, but also to study and apply the different
specifications and standards. When applying EMF-REST, designing Web services boils
down to providing the required data model as input and running the code generation
suite. Thus, EMF-REST can be used to obtain the core RESTful Web API allowing
developers to focus more on designing the REST client at an early stage of the devel-
opment process of a system. Even for web developers preferring to develop the REST
API themselves at a later stage, our generated one would be useful for prototyping and
validation purposes.
7.2 Scalability and Collaboration in MDE
Beside the application in the Web realm, EMF-REST also provides the basis for Web-
based model management. Many benefits can be achieved by moving model manage-
ment from classic environments (i.e., the Eclipse IDE) into distributed (i.e., Cloud)
architectures by the use of Web services. For instance, to cope with the increase of
MDE applications to large and more complex systems, which has led to performance
issues [16]. By using EMF-REST, developers have the ground to deploy the system in a
Platform-as-a-Service (PaaS) provider, in which model management would take advan-
tage of its scalability capabilities and may solve performance issues in MDE systems.
Thus, developers would not be limited by the capacity of their local machines in term of
memory and CPU. For instance, resource and time-consuming operations such as val-
idation or transformation would benefit from the scalable infrastructure of the current
Cloud providers (e.g., Amazon WS, Openshift).
Adopting a distributed system would also promote the collaboration between mod-
elers. As modeling activities rise and developer teams get geographicaly dispersed,
collaborative modeling environments are more and more necessary [4]. Using EMF-
REST at the metamodel level (i.e. the input of EMF-REST would not be a data model
but a metamodel framing the kind of models that could be created by calling the API
methods) would promote the collaborative development of new software models for the
project at hand or even the development of Domain-Specific Languages (DSLs). For
example, developers can work on an slice of the DSL while the others can provide live
feedbacks to improve and polish the DSL under development. Approaches such as Col-
laboro [8], currently providing a centralized collaboration environment, could benefit
from EMF-REST features to offer a distributed solution.
8 Related Work
Several efforts have been made to bring together MDE and Web Engineering. This
field is usually referred to as Model Driven Web Engineering (MDWE) and proposes
the use of models and model transformations for the specification and semiautomatic
generation of Web applications [24] [14] [21] [9] [27] [15] [13] [12] [17]. Mainly, data
models, navigation models and presentations models are used for this purpose.
Some of these works provide support for the generation of Web services as well,
but support for generation of RESTful APIs is very limited [22],[3] and [18]. Moreover,
these approaches require the designer to specifically model the API itself using some
kind of tool-specific DSL from which then the API is (partially) generated. Instead, our
approach is able to generate a complete RESTful API implementation from a plain data
9 Conclusion
In this paper we have presented EMF-REST, an approach to generate ready-to-run-and-
test RESTful Web APIs out of domain models. The generated APIs rely on well-known
libraries and standards, and also provide extra features such as validation and security.
We believe our approach fills an important gap between the Web and modeling tech-
nologies, thus enabling Web developers to leverage on modeling techniques to generate
RESTful Web APIs and MDE practitioners to bring their models into the Web. EMF-
REST has been released as an Eclipse-plugin and is available at [1].
As further work, we would like to work on a small configuration DSL to help de-
signers parameterize the style of the generated API (e.g., configuring the URIs to the
resources). Existing approaches, like WADL7and RSDL8, which also propose DSLs
to describe Web APIs, could be useful here. We are also interested in evaluating the
security and scalability of our approach and devise possible improvements (e.g., a more
fine-grained security mechanism or the implementation of different types of model stor-
age, e.g., NoSQL-based ones like Neo4EMF [6], at the server side). Last but not least,
we would also like to explore the benefits of using EMF-REST in combination with
client-side modeling environments, for instance, in Eclipse, thus enabling developers
to deal with large EMF models in a transparent way (i.e., models in Eclipse that are
remotely stored using an EMF-REST backend).
1. EMF-REST website. (accessed 02/05/15)
2. EMF. (accessed 02/05/15)
3. Towards Interoperability to the Implementation of RESTful Web Services: A Model Driven
Approach, author=Tavares, Nirondes and Vale, Samyr. In: ICONS conf. pp. 234–240 (2014)
4. Altmanninger, K., Seidl, M., Wimmer, M.: A Survey on Model Versioning Approaches. J.
Web Inf. 5(3), 271–304 (2009)
5. Alvarez, C., Casallas, R.: MTC Flow: A Tool to Design, Develop and Deploy Model Trans-
formation Chains. In: ACME workshop. pp. 1–9 (2013)
6. Benelallam, A., Gómez, A., Sunyé, G., Tisi, M., Launay, D.: Neo4EMF, A Scalable Persis-
tence Layer for EMF Models. In: ECMFA conf., pp. 230–241 (2014)
7. Brambilla, M., Cabot, J., Wimmer, M.: Model-Driven Software Engineering in Practice.
Morgan & Claypool Publishers (2012)
8. Cánovas Izquierdo, J.L., Cabot, J.: Enabling the Collaborative Definition of DSMLs. In:
CAiSE conf. pp. 272–287 (2013)
9. Ceri, S., Fraternali, P., Bongio, A.: Web Modeling Language (WebML): a Modeling Lan-
guage for Designing Web Sites. J. Comp. Netw. 33, 137–157 (2000)
10. Eclipse website: (accessed 02/02/15)
11. Fielding, R.T.: Architectural Styles and the Design of Network-based Software Architec-
tures. Ph.D. thesis (2000)
12. Fons, J., Pelechano, V., Albert, M., Pastor, O.: Development of Web Applications from Web
Enhanced Conceptual Schemas. In: ER conf., pp. 232–245 (2003)
13. Garzotto, F., Paolini, P., Schwabe, D.: HDM–a Model-based Approach to Hypertext Appli-
cation Design. ACM Trans. Inf. Syst. 11, 1–26 (1993)
14. Jose Escalona, M., Aragon, G.: NDT. A Model-Driven Approach for Web Requirements.
IEEE Trans. Softw. Eng. 34(3), 377–390 (2008)
15. Koch, N., Kraus, A.: The Expressive Power of UML-based Web Engineering. In: IWWOST
workshop. vol. 16 (2002)
16. Kolovos, D.S., Rose, L.M., Matragkas, N., Paige, R.F., Guerra, E., Cuadrado, J.S., De Lara,
J., Ráth, I., Varró, D., Tisi, M., Cabot, J.: A Research Roadmap Towards Achieving Scalabil-
ity in Model Driven Engineering. In: SMDE workshop. pp. 1–10 (2013)
17. Marco, B., Cabot, J., Grossniklaus, M.: Tools for Modeling and Generating Safe Interface
Interactions in Web Applications. In: ICWE conf. pp. 482–485 (2010)
18. Maximilien, E., Wilkinson, H., Desai, N., Tai, S.: A Domain-Specific Language for Web
APIs and Services Mashups. In: ICSOC conf., pp. 13–26 (2007)
19. Mulloy, B.: Web API Design - Crafting Interfaces that Developers Love. Apigee (2012)
20. OMG MOG Specification: (accessed 02/02/15)
21. Qafmolla, X., Nguyen, V.C.: Automation of Web Services Development Using Model Driven
Techniques. In: ICCAE conf. vol. 3, pp. 190–194 (2010)
22. Rivero, J.M., Heil, S., Grigera, J., Gaedke, M., Rossi, G.: MockAPI: An Agile Approach
Supporting API-first Web Application Development. In: ICWE conf. pp. 7–21 (2013)
23. Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modeling Language Reference Manual.
Pearson Higher Education (2004)
24. Schauerhuber, A., Wimmer, M., Kapsammer, E.: Bridging Existing Web Modeling Lan-
guages to Model-driven Engineering: A Metamodel for WebML. In: ICWE conf. (2006)
25. Selic, B.: The Pragmatics of Model-Driven Development. IEEE Softw. 20(5), 19–25 (2003)
26. Warmer, J., Kleppe, A.: The Object Constraint Language: Precise Modeling with UML.
Addison-Wesley (1999)
27. WebRatio: (accessed 02/05/15)
... As a result, many approaches use different technologies for a similar goal: generating REST API server or client implementations from syntactical contracts [68,69,70,71,72,73]. Some of the approaches generating the server code also generate the REST API documentation in various formats such as WADL. ...
The World Wide Web is mainly composed of two types of application components: applications and services. Applications, whether they are mobile or Web applications, i.e. intended to be used from a browser, have in common that they are a kind of text to holes and communicate with the services to customize the application for each user. It is therefore the service that owns and manages the data. To make this communication possible, the services offer APIs following the REST architecture. The management of the life cycle of a REST API is then a central element of the development of systems on the Web. The first step in this life cycle is the definition of the requirements of an API (functionality and software properties). Then, the technologies that will allow it to be designed, implemented and documented are chosen. It is then implemented and documented and put online. From then on, applications can use it. Then follows a phase of maintenance and evolution of the API, in which bugs are fixed and functionalities evolve to adapt to the changes of its users' expectations. In this thesis, we review the methods and technologies that accompany the developer during this life cycle. We identify two open challenges. First, there are many technologies for creating and documenting an API. Choosing the most relevant technologies for a project is a difficult task. As a first contribution of this thesis, we establish criteria to compare these technologies. Then, we use these criteria to compare existing technologies and propose three comparison matrices. Finally, to simplify this selection, we have developed an open-source wizard available on the Web, which guides the developer in his choice. The second challenge we have identified is related to the maintenance and evolution of REST APIs. The existing literature does not allow a REST API to evolve freely, without the risk of breaking the applications that use it (their clients). The second contribution of this work is a new approach to the co-evolution of REST APIs and their clients. We have identified that by following 7 rules governing the documentation of the API and the data they return in response to its clients, it is possible to create Web user interfaces capable of adapting to the majority of evolutions of REST APIs without producing bugs, nor breaking them and without even requiring the modification of their source code.
The generation of code templates from web API specifications is a common practice in industry. However, existing tools neglect the dependencies among input parameters (so-called inter-parameter dependencies), extremely common in practice and usually described in natural language. As a result, developers are responsible for implementing the corresponding validation logic manually, a tedious and error-prone process. In this paper, we present IDLGen, an approach for the automated generation of validation code for inter-parameter dependencies in web APIs. Specifically, we exploit the IDL4OAS extension for specifying inter-parameter dependencies as a part of OpenAPI Specification (OAS) files. To make our approach applicable in practice, we present an extension of the popular OpenAPI Generator tool ecosystem, automating the generation of Java and Python code for the management of inter-parameter dependencies in web APIs. Evaluation results show the effectiveness of the approach in accelerating the development of APIs, generating up to 9.4 times more lines of Java code than the current generator. This leads to average time savings ranging from 16 to 24 min when implementing API operations including between one and three dependencies, when compared to manual coding. More importantly, the generated code mitigates human errors, making web APIs significantly more reliable.
This paper advances our prior work in developing a modeling method for managing Node.js projects dependencies by adding a semantic analysis layer to the created models, benefitting from prior artifact-building research that makes it possible for diagrams of arbitrary semantics to be processed as RDF graphs. The purpose of models thus extends towards a knowledge-driven project management approach that handles a graph-based conceptualization of project management processes, development tasks and Node.js development resources (packages, APIs and their dependencies). With the continuous growth of the Node.js environment, managing complex projects that use this technology can be chaotic, especially when it comes to planning dependencies and module integration. The deprecation of a module can lead to serious crisis regarding various projects where that module was used; consequently, traceability of deprecation propagation becomes a key requirements in Node.js project management. The modeling method introduced in this paper provides a diagrammatic solution to managing module and API dependencies in a Node.js project. It is deployed as a modeling tool that can also generate REST API documentation and Node.js project configuration files that can be executed to install the graphically designed dependencies.KeywordsDomain-specific modeling method engineeringADOxxRDFNPM ecosystemREST API ecosystemDependency management
Full-text available
Modern web applications and software systems have shifted to relying on RESTful APIs, which are more susceptible to security threats such as injection attacks, authentication attacks, and data breaches. This article discusses the difficulties of performing security testing on RESTful APIs, such as input validation, authentication, and authorisation. It has been identified that vulnerabilities that affect security configuration include insufficient logging, faulty object-level authorisation, asset management, faulty function-level authorisation, and mass assignment. It concludes by summarising the findings and offering suggestions for maintaining the security of RESTful APIs using previous research studies.
The generation of code templates from web API specifications is a common practice in the software industry. However, existing tools neglect the dependencies among input parameters (so called inter-parameter dependencies), extremely common in practice and usually described in natural language. As a result, developers are responsible for implementing the corresponding validation logic manually, a tedious and error-prone process. In this paper, we present an approach for the automated generation of code for inter-parameter dependencies in web APIs. Specifically, we exploit the IDL4OAS extension for specifying inter-parameter dependencies as a part of OpenAPI Specification (OAS) files. To make our approach applicable in practice, we present an extension of the popular OpenAPI Generator tool ecosystem, automating the generation of Java and Python code for the management of inter-parameter dependencies in both servers and clients. Evaluation results show the effectiveness of the approach in accelerating the development of APIs, generating up to 9.4 times more code than current generators, while making APIs potentially more reliable.KeywordsWeb APIsScaffoldingCode generationOpenAPI generator
Full-text available
This study offers a step-by-step practical procedure from the analysis of the current status of the spare parts inventory system to advanced service level analysis by virtue of simulation-optimization technique for a real-world case study associated with a seaport. The remarkable variety and immense diversity, on one hand, and extreme complexities not only in consumption patterns but also in the supply of spare parts in an international port with technically advanced port operator machinery, on the other hand, have convinced the managers to deal with this issue in a structural framework. The huge available data require cleaning and classification to properly process them and derive reorder point (ROP) estimation, reorder quantity (ROQ) estimation, and associated service level analysis. Finally, from 247,000 items used in 9 years long, 1416 inventory items are elected as a result of ABC analysis integrating with the analytic hierarchy process (AHP), which led to the main items that need to be kept under strict inventory control. The ROPs and the pertinent quantities are simulated by Arena software for all the main items, each of which took approximately 30 minutes run time on a personal computer to determine near-optimal estimations.
Conference Paper
Full-text available
Web services based on the REpresentational State Transfer (REST) architectural style have become increasingly popular in recent years. REST provides several desirable features, such as simplicity and scalability; however, developing RESTful web services involves repetitive and trivial tasks that can be avoided through automatic code generation. Model-Driven Development (MDD) can be used to this aim, as it facilitates the construction of complex applications and can provide automatic code generation through transformations of models. This paper presents MDD4REST as a model-driven methodology, consisting of a framework and a process, for developing RESTful web services. MDD4REST takes advantage of Domain-Driven Design (DDD) to produce a rich domain model for web services. It provides an effective method for designing RESTful web services using modeling languages, and supports automatic code generation through transformation of models. In addition, MDD4REST has the capability to support modern web architectures and patterns, such as Microservice, Event-Driven, and CQRS.
Full-text available
Several industrial contexts require software engineering methods and tools able to handle large-size artifacts. The central idea of abstraction makes model-driven engineering (MDE) a promising approach in such contexts, but current tools do not scale to very large models (VLMs): already the task of storing and accessing VLMs from a persisting support is currently inefficient. In this paper we propose a scalable persistence layer for the de-facto standard MDE framework EMF. The layer exploits the efficiency of graph databases in storing and accessing graph structures, as EMF models are. A preliminary experimentation shows that typical queries in reverse-engineering EMF models have good performance on such persistence layer, compared to file-based backends.
Conference Paper
Full-text available
Software development processes are collaborative in nature. Neglecting the key role of end-users leads to software that does not satisfy their needs. This collaboration becomes specially important when creating Domain-Specific Modeling Languages (DSMLs), which are (modeling) languages specifically designed to carry out the tasks of a particular domain. While end-users are actually the experts of the domain for which a DSML is developed, their participation in the DSML specification process is still rather limited nowadays. In this paper we propose a more community-aware language development process by enabling the active participation of all community members (both developers and end-users of the DSML) from the very beginning. Our proposal is based on a DSML itself, called Collaboro, which allows representing change proposals on the DSML design and discussing (and tracing back) possible solutions, comments and decisions arisen during the collaboration.
Full-text available
This book discusses how model-based approaches can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE). MDSE practices have proved to increase efficiency and effectiveness in software development, as demonstrated by various quantitative and qualitative studies. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis. The aim of this book is to provide you with an agile and flexible tool to introduce you to the MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDSE instruments for your needs so that you can start to benefit from MDSE right away. The book is organized into two main parts. The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the well-known MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDSE in existing development processes. The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDSE projects. The book is targeted to a diverse set of readers, spanning: professionals, CTOs, CIOs, and team managers that need to have a bird's eye vision on the matter, so as to take the appropriate decisions when it comes to choosing the best development techniques for their company or team; software analysts, developers, or designers that expect to use MDSE for improving everyday work productivity, either by applying the basic modeling techniques and notations or by defining new domain-specific modeling languages and applying end-to-end MDSE practices in the software factory; and academic teachers and students to address undergrad and postgrad courses on MDSE. In addition to the contents of the book, more resources are provided on the book's website, including the examples presented in the book. Table of Contents: Introduction / MDSE Principles / MDSE Use Cases / Model-Driven Architecture (MDA) / Integration of MDSE in your Development Process / Modeling Languages at a Glance / Developing your Own Modeling Language / Model-to-Model Transformations / Model-to-Text Transformations / Managing Models / Summary
Conference Paper
Nowadays, Web services and others SOA-based applications have attracted more attention in the software industry. The RESTful Web Service becomes an important service architectural style due to its simplicity, heterogeneity and web-based format. One of the principal advantages of the REST architecture is the interoperability. However, different implementation languages and representation data formats can break interoperability, especially on semantic description of these services. In this paper, we propose the use of a model driven approach for the development of semantic RESTful Web services. Raising the development abstraction level, providing language-independent metamodels of services and semantic resources and by model transformations it is possible to develop interoperable complex services.
Conference Paper
This paper presents a tool called MTC Flow, which allows model-driven developers to design, develop, test and deploy Model Transformation Chains (MTCs). The tool offers a graphical DSL for defining MTC workflow models independently of the technologies that support the transformations. Using basic concepts such as metamodels, models and transformations (M2M, M2T and T2M) the user defines, executes and tests his MTC easily in the same development environment. MTC Flow has an abstraction layer to implement technology support. It facilitates the interoperability of model transformation and validation using the existing technologies without changes. Additionally, once the MTC is finished, MTC Flow offers an option to deploy it in any environment that support JAVA technology. The tool supports modularity and alternative execution paths of the MTCs. It was built on top of the Eclipse Modeling Framework (EMF) and the Graphical Modeling Framework (GMF). The tool offers a development environment using the extending capabilities of the Eclipse platform. We illustrate how MTC Flow supports MTCs development process using an example.
Conference Paper
As Model-Driven Engineering (MDE) is increasingly applied to larger and more complex systems, the current generation of modelling and model management technologies are being pushed to their limits in terms of capacity and efficiency. Additional research and development is imperative in order to enable MDE to remain relevant with industrial practice and to continue delivering its widely recognised productivity, quality, and maintainability benefits. Achieving scalability in modelling and MDE involves being able to construct large models and domain-specific languages in a systematic manner, enabling teams of modellers to construct and refine large models in a collaborative manner, advancing the state of the art in model querying and transformations tools so that they can cope with large models (of the scale of millions of model elements), and providing an infrastructure for efficient storage, indexing and retrieval of large models. This paper attempts to provide a research roadmap for these aspects of scalability in MDE and outline directions for work in this emerging research area.
Conference Paper
The relevance of a detailed and precise specification of the requirements is well known; it helps to achieve an agreement with the customer on software functionality, user friendliness and priorities in the development process. However, in practice, modeling of requirements is avoided in many projects, in particular in the Web domain, mainly due to short time-to-market. The objective of this work is to make requirements modeling more attractive providing a win-win situation. On the one hand such models are used to improve the developer-customer communication and on the other hand to generate draft design models, which can be used in further steps of a model-driven development approach, and therefore reduce the developers' efforts. We concretize the approach presenting a domain specific modeling language defined as an extension of the UML-based Web Engineering (UWE) profile and a set of model transformations defined to generate the content, navigation and presentation models of web applications. A social network application is used to illustrate UWE requirements and design models.
Conference Paper
In the last years, agile development methodologies have been widely adopted. However, they still lack support for API requirements while, at the same time, public RESTful APIs are fueling a rapid growth of web applications providing services built on other services. On the other hand, whereas Model- Driven Development techniques successfully increase the productivity in the development of data-intensive web applications, they lack the agility required when developing heterogeneous web applications with frequent requirement changes. In this paper we introduce MockAPI, an approach based on annotating user interface mockups that combines the advantages of agile approaches and Model-Driven Development. We introduce a metamodel for annotations and demonstrate how to derive running API prototypes as starting point for agile development. RESTful API best practices and API-first development are introduced into the agile process. The MockAPI approach defines a set of constraints to accelerate the development of web applications. We also show the results of a brief validation applying MockAPI to popular web sites.