UML-based Model-Driven REST API Development

Davide Rossi

Department of Computer Science and Engineering, University of Bologna, Bologna, Italy

Keywords:

UML, REST, Web Services, Model-Driven Development.

Abstract:

In the last few years we have witnessed the expansion of REST APIs as a method to implement machine-

to-machine interactions in open distributed systems. Recently REST APIs can also be found in several B2B

and enterprise scenarios that were previously reserved to alternative technologies such as SOAP-based Web

Services. Despite that, the development of REST-based solutions has remained mostly inspired by agile ap-

proaches with no or limited explicit modeling artifacts produced during the development process. This clashes

with software development methods in which modeling artifacts are expected to be available for all developed

software. Another problem is related to the resource-based nature of these APIs that miss standardized meth-

ods to discover and understand their capabilities akin to what object-oriented interfaces can do for objects and

services. In this paper we propose a model-driven approach to REST API development; this approach is com-

posed by two main steps: (i) UML modeling of the API using speciﬁc proﬁles and (ii) a model transformation

that exploits RAML, a recent RESTful API modeling language, as an intermediate notation that can be used

to automatically produce documentation and code for various languages/platforms.

1 INTRODUCTION

SOAP-based (W3C XML Protocol Working Group,

2007) web services have been the leading integration

technology in enterprise and B2B scenarios for the

last few years. Besides the obvious advantages re-

lated to standardization and interoperability there are

arguably two sets of reasons explaining this success.

First the availability of a rich technologies stack, en-

abling the implementation of the advanced non func-

tional requirements enterprise software is usually ex-

pected to meet (that includes features such as reli-

able messaging, advanced security, transactions sup-

port and so on). Secondly the ease of integration

with existing OO-based modeling methods: while

SOAP has been designed to adapt to different in-

teraction models (such as the message-based one) it

ﬁts naturally object oriented methods thanks to the

natural mapping of WSDL (Web Services Descrip-

tion Working Group, 2007) concepts such as port

type and operation to classes and methods. Further-

more, when UML (OMG, 2015b) is adopted in the

development process, SoaML (OMG, 2012) provides

a OMG-standardized approach for SOAP-based web

services modeling within service-based architectures,

allowing them to ﬁt nicely in most plan-based meth-

ods (such as the large family of UP-inspired (Jacob-

son et al., 1999) software development processes).

All of this, however, comes at a price: complexity.

SOAP and WSDL, mostly because of their roots in

XML schema, can pose difﬁculties to newcomers, and

the full WS-* stack (as the set of variously supported

speciﬁcations associated to SOAP-based web services

is usually called) has widely been criticized for its in-

tricacy which translates into elaborated software li-

braries and frameworks to deal with. RESTful API,

on the other side, make simplicity their aim. This cou-

ples well with the diffusion of agile approaches into

the realm of distributed programming and their pref-

erence to light, simple, composable technologies and

determined a wide adoption of REST-based APIs.

As this adoption started to interest more and more

enterprise software projects, the lack of a standard-

ized approach to declare and discover REST API

capabilities becomes a relevant issue. What is in

fact missing is a uniform way to model available re-

sources, allowable operations, messages parameters

and payload formats. This impacts software devel-

opment: on the provider side no modeling artifact is

available to guide the implementation of the API, on

the consumer side there is no formal documentation

on how to use the API. As a consequence also the

concept of a contract among the parties cannot be ad-

dressed.

The relevance of this problem can easily be per-

ceived by the number of recent proposals for both

194

Rossi, D.

UML-based Model-Driven REST API Development.

In Proceedings of the 12th International Conference on Web Information Systems and Technologies (WEBIST 2016) - Volume 1, pages 194-201

ISBN: 978-989-758-186-1

the description/modeling of the API itself and for

the modeling the data that are exchanged through it

(REST API data modeling is arguably one of the main

forces behind the development of JSON schema, cur-

rently an IETF Internet-Draft

). Among the existing

proposals we can list WADL

(Web Application De-

scription Language), Swagger

and RAML

(REST-

ful API Modeling Language). Notice that also WSDL

2.0 can be used to model RESTful services but has

been sparingly adopted. Although most of these pro-

posal are a welcome addition, when developing soft-

ware within a model-ﬁrst perspective it should be

taken into account that they (i) are not visual and (ii)

are not UML, that is they are not a standard, widely

used and tool-supported notation but are yet another

DSL (domain speciﬁc language) (Van Deursen et al.,

2000) to learn and integrate in the toolchain.

The research work presented in this paper aims

at deﬁning a standards-based approach to the model-

driven development (Schmidt, 2006) of REST APIs;

this approach has been designed under the guidance

of the following desiderata (we could have called

them requirements, but the idea of self-imposing re-

quirements seems a bit rhetoric), most of them stem-

ming from aforementioned considerations:

D1. The solution should be based on UML: it should

be possible to automatically transform an initial

UML model into code supporting the implemen-

tation of the API and its consumption; automatic

or semi-automatic generation of the API docu-

mentation is also welcome.

D2. The solution should be agnostic with respect to

the language and the platform used to implement

the API.

D3. The use of intermediate formats in the D1’s

transformation is possible but this should not in-

troduce novel DSLs.

D4. The solution should focus on structural model-

ing; behavioral aspects could be added with fu-

ture extensions but are not a primary concern at

this point.

D5. The solution should not require spe-

ciﬁc/proprietary software tools; a fully-FOSS

software-based tool chain is advisable.

The solution we present here is based on two main

contributions:

C1. A ﬂexible REST API modeling approach based

on leyered UML proﬁles.

http://tools.ietf.org/html/draft-zyp-json-schema-04

https://wadl.java.net/

http://swagger.io/

http://raml.org

C2. A model-driven transformation chain based

on an existing intermediate representation from

which documentation and code for various lan-

guages/platform can be reﬁned.

C3. A workﬂow deﬁning a method to implement the

proposed MDE approach.

This paper is structured as follows: section 2 dis-

cusses some of the existing proposals for the mod-

eling of RESTful APIs, some of which make use of

UML. A brief introduction to RAML can be found

here as well. In section 3 our proposal is presented:

starting with a set of desiderata we evaluate the possi-

ble options and end up with a method making use of

UML proﬁles and model-to-text transformations. In

section 4 a typical workﬂow adopting our approach is

presented. Section 5 concludes the paper and outline

future work.

2 RELATED WORKS

A few works are related to the approach we present

in this paper. In (Rathod et al., 2013) the authors pro-

pose an approach based on UML to model structural

(via class diagrams) and behavioral (via protocol state

machines) aspects of a RESTful API. In the class dia-

gram individual resources are mapped to plain classes

whereas collections are explicitly marked using a col-

lection stereotype. No further description of the oper-

ations is provided in this diagram: HTTP transactions

are used as triggers and state behaviors in the state

machine diagram. In a example the authors reﬁne (in

a way which is not described) an .NET implementa-

tion of the API provider. In (Rauf et al., 2010) the

authors propose the use of UML to model the com-

position of RESTful web services. Structural model-

ing happens in a way that is very similar to the pre-

viously discussed work. Behavioral modeling is also

very similar in which state machines are used and the

various HTTP invocations are mapped to call behav-

ior actions, the main difference being that in this case

what is modeled is the behavior of a composition of

services. A conceptual metamodel for RESTful APIs

is presented in (Schreier, 2011); also typical resource

types (such as primary, sub, list, ﬁlter, ...) are taken

into account. The author does not map these con-

cepts to any concrete modeling language leaving the

option to use them as the basis for a DSL or for a

UML extension. In (Ormeno et al., 2012) the au-

thors present a UML proﬁle for modeling RESTful

services based on the controllers and artifacts gener-

ated by Spring Roo

. The (structural) UML model is

http://projects.spring.io/spring-roo/

UML-based Model-Driven REST API Development

195

then transformed, using Enterprise Architect’s

pro-

prietary Code Template Framework, into a Spring

Roo application skeleton. In (Schreibmann, 2014) the

authors propose a model-driven approach for the de-

velopment of RESTful APIs. Their proposal is based

on a meta-model that serves as the basis for a DSL

used to model the API. By using Xtext

the DSL

can be converted into Java/JAX-RS. The IBM product

Rational Software Architect includes a (non-formally

described) REST proﬁle that is described in the doc-

umentation library

. Stereotyped class diagrams can

be transformed to JAX-RS-based Java code using pro-

prietary tools.

As stated in the introduction another aspect re-

lated to REST API is the surge of DSLs to doc-

ument/model them. A comparison between these

proposals is outside the scope of this paper, in our

work we focus on RAML. This is mostly due to the

fact that, as the ML (modeling language) letters in

the name implies, this proposal is more oriented to

the modeling of the API rather than simply to its

documentation/description in favor of potential con-

sumers, enabling what it s called an API design-ﬁrst

approach. RAML is a non-proprietary, vendor-neutral

open speciﬁcation. The workgroup developing the

speciﬁcation includes representatives from MuleSoft,

VMware and Cisco. A RAML model is represented in

a text document adopting the YAML

format (a pop-

ular human friendly data serialization standard) and

contains a structural description of the API: its re-

sources, their methods, the URI and query parameters

used in invocations, the format for the body of the ex-

changed entities, and so on. The RAML developers

and a large user community also make available var-

ious tools (usually as open source software), among

them several converters to transform RAML speciﬁ-

cations in documentation or skeleton code for many

language/platform pairs.

3 FROM UML TO REST APIs

The solution we designed is meant to satisfy the

desiderata exposed in the introduction section. What

follows is a brief discussion of how these requirement

affected our choices.

D1 implies that a new modeling notation should

not be developed and if a metamodel is deﬁned it

http://www.sparxsystems.com/products/ea/

https://eclipse.org/Xtext/

http://www.ibm.com/developerworks/rational/library/

design-implement-restful-web-services/

http://www.yaml.org/

should then be possible to express it using UML pro-

ﬁles. This strongly drove us toward the adoption of a

UML proﬁle.

D2 implies that a starting model should be eas-

ily transformed into different language/platform tar-

gets. As a result, no implementation-speciﬁc con-

cerns should percolate upward to the starting nota-

tion. But this also means that, in order to max-

imize the adoption of the solution, several trans-

formation targets should be supported (like PHP,

Javascript/Node.js, Java/JAX-RS, and so on). Being

this far from trivial we started considering the adop-

tion of an intermediate notation even more appeal-

ing if that has available code generators that can be

adopted in the tool chain.

D3 goes in this very same direction: if the analysis

of the other requirements drive toward the adoption of

an intermediate notation, this notation should be an

existing one, allowing the adoption of existing tools

and avoiding the need to learn yet another DSL by the

development team members.

Taking into account also D4 and D5 we decided

to adopt an intermediate RAML artifact. The deci-

sion to use RAML impacts the deﬁnition of the ini-

tial proﬁle. As usual when adopting transformations

in model-driven approaches, the problem of seman-

tic equivalence arises: if the starting notation contains

more information than the target, this information is

inevitably lost in the transformation. On the other

side, if the target notation contains more information

then it is possible that the resulting artifact needs to be

furtherly modiﬁed to add information if that is used

in later stages. Since RAML can express implemen-

tation details (such as the schema of the payloads or

the authentication mechanisms) that can be fruitfully

exploited in later transformations and since, by de-

sign, we decided that these details should not be part

of the UML proﬁle, it is pretty obvious that we are in

the second of the two aforementioned cases. What

this means is that the RAML ﬁle produced by the

UML-to-RAML transformation is a skeleton contain-

ing structural information and it has to be enriched

with additional details before reﬁning it in successive

artifacts. The modiﬁcation of an intermediate artifact

in model-driven approaches is always problematic:

what happens when the transformation producing the

original version of the artifact is re-executed? Should

the artifact be overwritten and all the additional ele-

ments discarded? For model-to-text transformations

most of the times we witness solutions based on the

creative use of comments to mark elements that have

to be preserved and/or elements that can be overwrit-

ten. RAML wisely includes a layering mechanism

(based on so called overlays) that allow manual re-

WEBIST 2016 - 12th International Conference on Web Information Systems and Technologies

196

ﬁnements of a speciﬁcation to take place in extension

artifacts without the need to modify the initial ﬁle pro-

duced by the transformation, allowing its regeneration

without having to worry about overwriting it. While

this is a viable solution for most scenarios we still

would like to support development strategies in which

adding as much information as possible in the initial

UML model is the preferred option. To make this pos-

sible we decided to develop a second UML proﬁle,

meant to be used as a second layer on top of the ﬁrst,

more general proﬁle. For the ﬁrst proﬁle we evaluated

the use of the existing ones discussed in the related

works section but most of them either included a rele-

vant behavioral part or are not fully documented (as is

the case for the IBM proﬁle, that we used as inspira-

tion). Given D5 we decided to create the two proﬁles

using the open source Papyrus

modeler. The result-

ing artifacts should be usable in other UML tools with

no or minimal effort.

The UML-to-RAML transformation should ac-

cept UML models using the generic proﬁle (the

REST proﬁle) and use the information added using

the second proﬁle (the RAML proﬁle) if present.

Since no formal MOF-based meta model exists for

RAML we decided to avoid going in the direction

of a model-to-model transformation (potentially using

QVT (OMG, 2015a) or ATL (Jouault et al., 2006)) tar-

geting the RAML metamodel with a later model-to-

text transformation to create the actual RAML YAML

ﬁle. The transformation is then a model-to-text from

UML+REST/RAML proﬁles to the RAML YAML

ﬁle.

The architecture (in the sense of signiﬁcant design

decisions that characterize a solution (Buschmann

et al., 2007)) we propose is shaped as follows:

• A novel generic REST API proﬁle focusing on

structural aspects is developed, this proﬁle is de-

signed so that no implementation details perco-

lates upward.

• A RAML-speciﬁc proﬁle is developed, meant to

be used along the generic one.

• An UML-to-RAML transformation is deﬁned.

The transformation is implemented with the OMG

MOF Model to Text Language (MTL) standard

(OMG, 2008).

• Existing (open source) tools allowing RAML

speciﬁcations to be transformed into documen-

tation/code for various languages/platforms are

used.

• The proﬁles and the MTL code is made available

as open source software

https://eclipse.org/papyrus/

https://bitbucket.org/DavideRossi/uml2raml

3.1 Two UML Proﬁles for REST APIs

The two layers (REST only and REST with RAML)

approach has been discussed before. This approach

could be realized by using different techniques: the

RAML proﬁle could be a subproﬁle of the REST

one or they could be totally distinct. We decided to

chose for the latter option: in the tool we used sub-

proﬁles have to be deﬁned in the same model as the

proﬁle they depend on and we wanted to make the

REST proﬁle available as fully standalone. Designing

a UML proﬁle for REST APIs does pose some techni-

cal problem. In a REST API we usually ﬁnd two kind

of elements: single resources and collections. Con-

sider a simple API to access the details for a set of

persons. The path to access persons such as Alice,

Bob and Cecilia could look like /api/persons/alice,

/api/persons/bob, /api/persons/cecilia. That is, the

path speciﬁcation /api/persons/{name} can be used to

access all person resources. But also /api/persons in-

dicates a resource, in this case a collection that, for

example, can be queried to have the list of all the

available persons or be used (possibly using a POST

factory pattern (Pautasso, 2014) to create new per-

sons. In an API like this the elements we want to

model are the ones accessed via /api/persons/{name}

(that represent a class) and the one at /api/persons that

represent a single resource (a collection). Mapping

these concepts in a OO way would mean to use classes

for /api/persons/{name} and instances of a collection

type for /api/persons. Not only this is hardly achiev-

able in standard UML even mixing imports and pro-

ﬁles but, most importantly, would result in a very

unnatural way of modeling. Some of the existing

proposal use distinct stereotypes to mark single re-

sources and collections but this distinction is not re-

ally needed from a structural point of view. For this

reason we decided for a simpler, yet conceptually not

fully accurate, solution: model both concepts with the

same stereotyped class. The resulting proﬁle is very

straightforward and is represented in ﬁgure 1. An ex-

ample of its application can be seen in ﬁgure 2.

The approach is quite straightforward: an API

is contained in a API stereotyped package. Re-

sources are modeled as Resource stereotypes classes

Figure 1: The REST proﬁle as modeled in Papyrus.

UML-based Model-Driven REST API Development

197

Figure 2: A sample model using the REST proﬁle.

within these packages. These resources could be

non-correlated and characterized by their own abso-

lute path or can be explicitly organized in hierarchies

by tying them together with a ResourcePath stereo-

typed dependence. In the latter case the path of a

sub-resource is derived from the path of the super-

resource it references and from the path property of

the ResourcePath stereotype that is applied to the de-

pendency edge.

The second proﬁle contains much more details

with respect to the ﬁrst one, since it has to capture sev-

eral aspects that can be modeled in RAML (notice that

we decided not to represent the whole RAML meta-

model). That is, there are valid RAML documents

that cannot be represented by the proﬁle. This was

never our intention: the proﬁle is meant to help the

design of REST APIs via UML and convert them to

RAML descriptions adopting the most usual REST

API patterns, not to work as a RAML visual notation.

If the use of very speciﬁc RAML constructs is need,

the suggestion is to make use or RAMLs own layer-

ing mechanism to enrich the speciﬁcation produced

by the transformation of the UML model. Despite be-

ing limited, the RAML proﬁle can easily be misused

by trying to model too many details, leading to intri-

cate, unreadable diagrams. Also consider that some

of the stereotypes’ properties are deﬁned with respect

to data types deﬁned in the proﬁle, and the values of

these properties cannot be displayed by most existing

UML modelers.

The proﬁle, instead, is intended to be used along-

side the modularization and reuse mechanisms pro-

vided by RAML: data types, resource types and traits.

RAML data types can be derived by a set of built-in

types (by using scalar specialization, inheritance, ar-

rays, enumerations, unions and maps) or can refer-

ence JSON or XML schema. RAML resource types

are partial resource deﬁnition specifying common

characteristics such as security schemes and meth-

ods. RAML traits are partial method deﬁnitions spec-

ifying common characteristics such as description,

headers, query string parameters, and responses. So,

while is is possible to use the proﬁle to specify that

a POST method on a resource accepts a JSON pay-

load composed by a name and a birthDate, the sug-

gested way to proceed is to deﬁne a PersonType with

these properties in an external ﬁle that is imported,

and use the proﬁle to specify that the method accepts

a PersonType payload. Similarly, while is possible to

use stereotypes properties to specify that a collection

resource accepts query parameters such as start and

count in its GET method, the suggested way to pro-

ceed is to deﬁne a ”paged” trait and refer to that in the

UML model. The same applies to resource types.

For terseness we are omitting the other details of

the RAML proﬁle here; an example of a model using

the two proﬁles together can be found in ﬁgure 3.

Notice the application of stereotypes from both

proﬁles in elements such as in the outer package rep-

resenting the API. One advantage of this approach is

that by ﬁltering out the whole second proﬁle, a valid

view of the model with respect to the generic REST

proﬁle can be easily obtained.

3.2 From UML to RAML

To convert the UML model adopting one or both the

proﬁles we decided to design a model-to-text transfor-

mation using Acceleo

an Eclipse-based implemen-

tation of the OMG MTL standard; since both Papyrus

and Acceleo are part of the Eclipse Modeling Project

this should limit interoperability issues. The trans-

formation needs the REST proﬁle to be used; if the

RAML proﬁle is also applied the additional informa-

tion is used. The basic structure of the API is de-

rived from the resources and their hierarchies (speci-

ﬁed using the ResourcePath stereotyped dependencies

as detailed above). MTL is a transformation language

similar to XSLT. Templates are used to deﬁne how to

transform speciﬁc parts of the input UML model (the

one matching a pattern speciﬁed in OCL); functional

expression (based on a superset of the OCL language)

are used to manipulate model elements and produce

the textual result. The following snippet

1 [template public generateAPI

2 (aPackage : Package) ?

3 (hasStereotype(aPackage, ’RestProfile::API’))]

shows the deﬁnition of a template (generateAPI) to

be applied to all the package elements in the source

model to which the API stereotype deﬁned in the

RestProﬁle has been applied. hasStereotype is a util-

ity function deﬁned in the same MTL module. Inside

https://www.eclipse.org/acceleo/

WEBIST 2016 - 12th International Conference on Web Information Systems and Technologies

198

Figure 3: A sample model using both proﬁles.

the template all the Resource stereotyped classes con-

tained in the package identiﬁed by the generateAPI

can be iterated by using

1 [for (e : Element | aPackage.ownedElement->

2 select(e1 | e1.oclIsTypeOf(Class) and

3 hasStereotype(e1, ’RestProfile::Resource’)))]

An example fragment of the output of the transfor-

mation on the simple model of ﬁgure 3 is as follows:

1 #%RAML 1.0

2 title: ACME API

3 version: v2

4 baseUri: https://api.acme.org/{version}

5 mediaType: application/json

6 description: |

7 This is a sample RAML API generated

8 from a UML model

9 securitySchemes:

10 - oauth_2_0: !include security/oauth_2_0.raml

11 types: !include types/products.raml

12 resourceTypes:

13 collection: !include types/collection.raml

14 traits: !include traits/common.raml

15 securedBy: [oauth_2_0]

16 documentation:

17 - title: Home

18 - content: |

19 Welcome to the ACME API documentation

21 /products

22 displayName: Products

UML-based Model-Driven REST API Development

199

23 type: collection

24 get:

25 description: Get a list of products

26 is: [paged, secured, rateLimited]

4 SUGGESTED WORKFLOW

Having tried this approach with a few realistic test

cases we gained some experience and we developed

a feel for how to approach the modeling phase. As

previously suggested good modeling assumes that

the modularization and reuse features of RAML are

adopted. Resource types and traits usually respond

to patterns an are deﬁned in common libraries and

reused among different projects so most of the times

no explicit modeling is required (usually some refac-

toring is needed, though). The situation is a little

different for data types: these are usually domain-

speciﬁc so reuse is not an option. RAML has a well-

deﬁned data model and it could be interesting to cre-

ate a UML proﬁle allowing the deﬁnition of RAML

types. Many times, however, the RAML data model

is ditched in favor of JSON schema and XML schema

(something that is fully supported by RAML) so we

saw little value in another proﬁle and decided to re-

consider it as a potential future work. What follow is

the typical workﬂow we suggest when adopting our

approach.

1. A UML model adopting the generic REST proﬁle

is created to deﬁne the structure of the API (the

available resources and their topology).

2. Data is modeled considering all the payloads for

all the resources’ HTTP methods presented in the

model. This is usually realized using either JSON

schema or XML schema. If needed RAMLs own

type system can be used.

3. Traits common among different methods (such

as authentication mechanisms, pagination for re-

sources, REST factory pattern and so forth) are

deﬁned. The same is performed with resource

types. Both are usually reused from repositories,

libraries or other projects.

4. The RAML proﬁle is added to the UML model

and stereotypes are used to characterize resources

with respect to resource types, methods with re-

spect to traits and payloads and query parameters

with respect to data types.

The resulting UML model is clear, readable and, once

feeded to the model-to-text transformation, produces

a RAML ﬁle that can be used for successive transfor-

mation with no or minimal editing.

All the activities of this workﬂow can be realized

with open source software tools.

5 CONCLUSIONS AND FUTURE

WORK

In this paper we presented a UML-based model-

driven approach for the development of RESTful

APIs. An initial UML model adopting one or two

proposed proﬁles is created and can be automati-

cally transformed into a RAML ﬁle. Depending of

the information contained in the UML model, this

RAML speciﬁcation can be directly used to automat-

ically create documentation and code in various lan-

guages/platform pairs or can be extended using a lay-

ering mechanism before further transformations. Sev-

eral design alternatives for the method have been dis-

cussed and the adopted ones have been chosen to ad-

dress a set of desiderata stemming from an analysis of

the state of the art. As it is usual in these cases, these

decisions make sense in the speciﬁc context we de-

scribed, in other contexts other decisions would pos-

sibly be preferable. Also notice that we not claim

that this is an overall better approach with respect to

other existing ones based on DSLs: we are present-

ing an option for those who value the use of UML

in their workﬂows. Future works on this subject in-

clude data modeling and the development of an envi-

ronment based on patterns and libraries so that a sim-

pliﬁed intermediate proﬁle can be used instead of the

full RAML one to model in detail most RESTful APIs

with minimal or no knowledge of the intermediate no-

tation.

ACKNOWLEDGEMENTS

The research presented in this paper has been partially

funded by the Italian grant PRIN in the context the

IDEAS project.

REFERENCES

Buschmann, F., Henney, K., and Schimdt, D. (2007).

Pattern-oriented Software Architecture: On Patterns

and Pattern Language, volume 5. John wiley & sons.

Jacobson, I., Booch, G., Rumbaugh, J., Rumbaugh, J., and

Booch, G. (1999). The uniﬁed software development

process, volume 1. Addison-wesley Reading.

Jouault, F., Allilaire, F., B

ezivin, J., Kurtev, I., and Val-

duriez, P. (2006). ATL: a QVT-like transformation

language. In Companion to the 21st ACM SIGPLAN

WEBIST 2016 - 12th International Conference on Web Information Systems and Technologies

200

symposium on Object-oriented programming systems,

languages, and applications, pages 719–720. ACM.

OMG (2008). MOF Model to Text Transformation Lan-

guag.

OMG (2012). Service oriented architecture Modeling Lan-

guage (SoaML).

OMG (2015a). Meta Object Facility (MOF) 2.0

Query/View/Transformation (QVT).

OMG (2015b). Uniﬁed Modeling Language (UML).

Ormeno, E., Lund, M., Aballay, L., and Aciar, S. (2012).

An UML proﬁle for modeling RESTful services. In

13th Argentine Symposium on Software Engineering,

ASSE 2012, pages 119–133.

Pautasso, C. (2014). RESTful web services: principles, pat-

terns, emerging technologies. In Web Services Foun-

dations, pages 31–51. Springer.

Rathod, D. M., Parikh, S. M., and Buddhadev, B. (2013).

Structural and behavioral modeling of RESTful web

service interface using UML. In Intelligent Sys-

tems and Signal Processing (ISSP), 2013 Interna-

tional Conference on, pages 28–33. IEEE.

Rauf, I., Ruokonen, A., Systa, T., and Porres, I. (2010).

Modeling a composite RESTful web service with

UML. In Proceedings of the Fourth European Confer-

ence on Software Architecture: Companion Volume,

pages 253–260. ACM.

Schmidt, D. C. (2006). Guest editor’s introduction: Model-

driven engineering. Computer, 39(2):0025–31.

Schreibmann, V. (2014). Design and Implementation of a

Model-Driven Approach for RESTful APIs. In Proc.

Fifth IEEE Germany Students Conference.

Schreier, S. (2011). Modeling restful applications. In

Proceedings of the second international workshop on

restful design, pages 15–21. ACM.

Van Deursen, A., Klint, P., and Visser, J. (2000). Domain-

Speciﬁc Languages: An Annotated Bibliography. Sig-

plan Notices, 35(6):26–36.

W3C XML Protocol Working Group (2007). Latest SOAP

versions.

Web Services Description Working Group (2007). Web Ser-

vices Description Language (WSDL) 1.1.

UML-based Model-Driven REST API Development

201