Hypermedia: The Key to RESTful Web Applications

Patrick B. M. M

uller, Tobias Fertig, Henry Vu and Peter Braun

Faculty of Computer Science and Business Information Systems, University of Applied Sciences W

urzburg-Schweinfurt,

Sanderheinrichsleitenweg 20, 97074 W

urzburg, Germany

Keywords:

Model-driven, MDSD, Metamodel, Web Engineering, Web Components, Polymer, Graphical User Interfaces,

REST, RESTful Web Clients, Hypermedia.

Abstract:

Implementing the hypermedia constraint for RESTful Systems is a challenging task for most developers. This

is due to the lack of information about how to implement hypermedia on the client-side correctly. Therefore,

new tools are required to support developers with the implementation of the hypermedia constraint. We pro-

pose a model-driven approach that allows developers to deﬁne a RESTful System as a ﬁnite-state machine:

states represent resources and transitions represent hypermedia links. We present a metamodel that our gene-

rator can process to generate Polymer Web Applications. These web applications fulﬁll all REST constraints

deﬁned by Fielding. Therefore, developers do not have to implement the hypermedia constraint themselves.

Our approach simpliﬁes the development of RESTful Web Applications and reduces the development efforts.

Moreover, we describe how RESTful Web Applications can be derived from ﬁnite-state machines.

1 INTRODUCTION

Over the past few decades, the World-Wide Web has

become a global information system. This was ena-

bled by the scalable and reliable architecture of the

Web. It was designed for the rapid growth of users

and applications without knowing the term hyperme-

dia. The precursor of hypermedia was then called hy-

pertext, which is why the Hypertext Transfer Protocol

(HTTP) was speciﬁed.

In 2000, Fielding derived Representational State

Transfer (REST) as the architectural style for distribu-

ted hypermedia systems in his thesis (Fielding, 2000).

This architectural style meets the requirements of the

modern Web and can be combined well with HTTP.

Fielding deﬁned six constraints that determine how

a web application should behave to ensure certain

quality criteria. The quality criteria include scalabi-

lity and performance requirements. In his thesis, he

deﬁnes ﬁve mandatory and one optional constraint.

However, he just explains those constraints and gi-

ves no guidance or recommendation on how to im-

plement them. Therefore, false interpretations were

made, which is why developers misunderstand the

REST constraints. For this reason many web applica-

tions do not meet the quality requirements anymore.

The Hypermedia As The Engine Of Application

State (HATEOAS) constraint was most misunder-

stood and discussed. HATEOAS describes how the

client and the server should communicate via hyper-

media, which is why the constraint is often referred

to as the hypermedia constraint. Many developers be-

lieve the constraint is optional, but this is denied by

Fielding in his blog (Fielding, 2008). Fielding him-

self deﬁned the hypermedia constraint as mandatory,

while in contrast the Richardson Maturity Model deﬁ-

nes hypermedia as the highest degree of RESTful Ap-

plications (Webber et al., 2010). Therefore, Richard-

son implies the hypermedia constraint to be optional,

which was not ever the intention of Fielding.

The implementation of all REST constraints pre-

sents many developers with a great challenge. So we

are looking for an approach to simplify the develop-

ment of RESTful Web Applications. Formal models

can support developers by providing an abstract view

of software systems. Model-driven Software Deve-

lopment (MDSD) also uses formal models to gene-

rate code (V

olter et al., 2013). A similar approach

based on formal models are the Low Code Develop-

ment Platforms (Richardson et al., 2014).

Schreibmann et al. proposed a model-driven ap-

proach to generate RESTful APIs using metamodels

(Schreibmann and Braun, 2015). These metamodels

describe the REST domain using ﬁnite-state machi-

nes (ε-NFAs) after Zuzak et al. (Zuzak et al., 2011).

These ε-NFAs are easy to understand and can be

used to describe RESTful Systems on a higher le-

vel of abstraction. However, developers still have

378

Müller, P., Fertig, T., Vu, H. and Braun, P.

Hypermedia: The Key to RESTful Web Applications.

DOI: 10.5220/0006927103780387

In Proceedings of the 14th International Conference on Web Information Systems and Technologies (WEBIST 2018), pages 378-387

ISBN: 978-989-758-324-7

to implement hypermedia-driven frontends by them-

selves. Since there is not much information avai-

lable about how to build RESTful APIs correctly,

there is even less information about hypermedia-

driven clients. Developers are facing the challenge

of implementing the complex hypermedia constraint.

Therefore, we propose a MDSD approach to generate

RESTful Web Applications that fulﬁll all REST con-

straints. The generator is an extension to our model-

driven approach proposed by Schreibmann et al.

Within this work we are focusing on the following

research questions:

Q1) How can RESTful Web Applications be derived

from ﬁnite-state machines?

Q2) How can a model-driven approach support deve-

lopers building RESTful Web Applications?

Q3) Can the hypermedia constraint be fulﬁlled trans-

parently without manual efforts of individual de-

velopers?

To answer our research questions we will summarize

related work in Section 2. We will show that models

can ease the development of software systems. After-

wards, we will give a short summary of the deﬁnition

of ﬁnite-state machines for RESTful Systems. More-

over, we will give an overview of existing approaches

for generating web applications. In Section 3 we sum-

marize our project GeMARA and give a short intro-

duction into how our metamodel works. In Section 4

we summarize the different challenges we had to face

during our work. Afterwards, in Section 5 we pro-

pose our model-driven approach. We used Polymer

as a library for web components (Evans, 2015) and

solved the previously mentioned challenges. Finally,

in Section 6 we summarize our results, give answers

to our research questions, and show some limitations

of our generators. We end with a summary of future

work and how we will continue to use our ﬁndings.

2 RELATED WORK

Models are a common practice in software engineer-

ing. Already in 1992 Jacobson et al. proposed mo-

deling as tool for object-oriented programming (Ja-

cobson, 1992). Moreover, in 1995 relational models

were introduced for databases in the third manifesto

(Darwen and Date, 1995). Since then and maybe even

earlier engineers routinely create models when analy-

zing and designing complex systems in order to ab-

stract those systems and their environment.

The adjective driven in MDSD emphasizes that

this paradigm assigns models a central and active role.

In other words models are as important as source

code. MDSD is a discipline in software engineering

to generate runnable source code from metamodels

that allow domain developers to more accurately des-

cribe the domain’s problem space by abstracting from

the underlying programming language (V

olter et al.,

2013).

Therefore, we required a formal model to describe

REST. Zuzak et al. presented a model of RESTful

Systems based on a ﬁnite-state machine (ε-NFA) for-

malism, which should create a better understanding

of the architectural style REST (Zuzak et al., 2011).

They described three main parts of ε-NFA operations:

the Input Symbol Generator, the Transition Function

and ﬁnally the Current State. Their mapping of REST

to an ε-NFA can easily be transformed into a metamo-

del. However, they mainly focused on GET requests

in their work. So we had to extent the model for the

other HTTP verbs as well. Afterwards, we had a solid

metamodel to abstract from the complex architectural

style REST.

There is a lack of information about how to im-

plement hypermedia on the client-side. Besides Mike

Amundsen’s book there are no recommendations for

building effective hypermedia-based client applicati-

ons (Amundsen, 2017). Amundsen’s approach should

lead to a reduction of custom client code, as his ap-

proach works in general for every RESTful System.

He recommends that a server emits templates that are

processed by a client. The client uses the templa-

tes to render the Graphical User Interface (GUI) of

the web application. If actions for updating or de-

letion are included in the template, the client will

render the associated buttons. In this case, the bac-

kend developer decides what to display in the fron-

tend. Frontend developers cannot inﬂuence the appea-

rance of the web interface. Because his approach is

not model-driven, the backend developer is responsi-

ble for implementing the REST constraints correctly.

Thus, even with Amundsen’s approach, a faulty im-

plementation of the REST constraints is still possible.

Moreover, Amundsen did not use any formal models

we could use for our model-driven approach. The-

refore, we had to implement a different approach to

enable hypermedia on the client-side.

The idea to generate web frontends is not a new

one. In 2003 Shimomura et al. presented their ap-

proach to generate web applications based on images

(Shimomura et al., 2003). The motivation was to ease

the development process and help developers to built

web applications faster. In 2007 Jakob et al. released

a graphical modeling tool to deﬁne models and gene-

rators for data management web applications (Jakob

et al., 2007). The past shows that generators for web

applications worked for different domains. Even no-

Hypermedia: The Key to RESTful Web Applications

379

wadays more and more approaches for frontend ge-

neration are proposed. Beltramelli proposed an ap-

proach to generate GUIs. His approach is based on

artiﬁcial intelligence, which analyzes a screenshot of

the desired GUI and uses it to generate the code for

the web application (Beltramelli, 2017). The disad-

vantage with this method is that a GUI must already

exist - at least in form of a screenshot. Because Bel-

tramelli works independently of the REST domain,

and we cannot provide screenshots for every RESTful

Web Application, we still need a different approach.

Another approach to generate frontends was pro-

posed in 2018 by Jaber et al. They developed a meta-

model that describes GUIs for Android Applications

at a higher level of abstraction (Jaber et al., 2018).

The developers use their metamodel to determine

which control widgets to display on each view of the

Android Application. A generator processes this me-

tamodel to generate the code of the Android Appli-

cation. Unfortunately, this metamodel is not suitable

for our purposes because of the technical reference

to the Android domain. Furthermore, Android’s pro-

gramming model is very different from conventional

web development techniques. Additionally, the me-

tamodel lacks important REST speciﬁcations because

states, resources, or attributes are not considered. For

these reasons, we decided to design our own metamo-

del for generating RESTful Web Clients.

There are many proven techniques and practices in

the literature that support the successful implementa-

tion of a model-driven solution. Voelter et al. recom-

mended an approach that is divided into three steps

olter et al., 2013): First, building a reference imple-

mentation. Second, separate domain-speciﬁc and ge-

neric code. Third, build the generator for the domain-

speciﬁc code. We used this approach to build our

own metamodel and our own generator for REST-

ful Web Applications. We chose MDSD because this

approach not only reduces the burden on the deve-

lopment team but can also improve the quality, efﬁ-

ciency, and predictability of large-scale software de-

velopment due to its automation potential (Kelly and

Tolvanen, 2008).

3 GeMARA

The goal of our research project is to develop Genera-

tors for distributed Mobile Applications based on RE-

STful Architecture (GeMARA) using a model-driven

approach. Accordingly, applications are no longer de-

veloped individually, but are described by an abstract

model from which source code and other artifacts are

generated.

We proposed our approach in 2015 (Schreibmann

and Braun, 2015). Back then we were able to generate

RESTful APIs including the persistence layer. Our

generators were written with Xtext (Efftinge, 2014b)

and Xtend (Efftinge, 2014a). For the architecture we

used the recommendations of Bettini (Bettini, 2013).

However, as our project matured, the maintenance of

our generators got a time consuming task. Therefore,

we cut loose from Xtext and Xtend and developed

our own internal Domain-speciﬁc Language (DSL) in

Java (Fowler, 2010). The latest DSL describes RE-

STful Systems as ε-NFAs according to (Zuzak et al.,

2011):

States are deﬁned by the HTTP Verb and the re-

source representation. Transitions represent the hy-

permedia links. Subresources can also be deﬁned

within our metamodel. With those subresources we

can describe relations between resources, for exam-

ple between users and their addresses.

We can generate every RESTful System descri-

bed as ε-NFA. By now it is possible to generate web

clients. Moreover, we are generating test cases for

the RESTful API (Fertig and Braun, 2015) and hyper-

media tests (Vu et al., 2017). The generated source

code can be deployed out of the box. However, so-

metimes manual adjustments are necessary. Those are

also supported by our approach using dependency in-

jection.

In order to generate RESTful APIs, further re-

strictions of the REST domain are necessary. The six

constraints deﬁned by Fielding (Fielding, 2000) are

not enough to apply a model-driven approach. The-

refore, we had to deﬁne a subset of the REST dom-

ain. We can guarantee that the generated RESTful

Systems fulﬁll the REST constraints. However, it is

possible that there are RESTful Systems we cannot

generate in the same way they were written manually

before. These restrictions of constraints mainly affect

the types of states. We believe that a RESTful API

must support at least the following ﬁve state types:

GetCollectionResource, GetSingleResource, PostRe-

source, PutResource, and DeleteResource. Figure 1

shows an example of a lecturer domain modeled as a

ε-NFA.

These states can be connected according to a ﬁxed

pattern via transitions which gives a generic structure

of a RESTful API. We also divide the ε-NFA states

into a primary and secondary level. States of the pri-

mary level offer functionalities users can use to re-

trieve or manipulate main resources. Secondary level

states can be used to link resources to other resources.

The secondary level can be reached after a resource

has been retrieved at the primary level - via the Get-

SingleResource State. Table 1 shows the functionali-

APMDWE 2018 - 3rd International Special Session on Advanced practices in Model-Driven Web Engineering

380

GetCollection

Get All Lecturers

GetSingle

Get One Lecturer

Post

Create One Lecturer

Delete

Delete One Lecturer

Put

Update One Lecturer

GetCollection

Get All Charges

of One Lecturer

GetSingle

Get One Charge

of One Lecturer

Delete

Delete Link to

One Charge

Post

Create Charge

And Link

Put

Create Link

To Charge

Primary Layer Secondary Layer

Figure 1: The ε-NFA for the lecturer domain. On the left, there is the ‘Primary Layer’ containing all states for the manipulation

of lecturer resources. On the right, there is the ‘Secondary Layer’ containing all states for the manipulation of links between

lecturer resources and their charges. The arrows represent possible transitions between states. A client can always return to

the s0 state: transitions were removed for sake of readability.

ties offered by the state types. Depending on which

level a state is located, the functionality changes.

The states are connected by transitions which

show the client the next possible states. Transitions

consist of a URL, a RelationType and a MediaType.

The URL indicates where the state of a resource is

located. Based on the relation type, the client can de-

cide which HTTP verb to use for the request. The

media type tells the client which representation of the

resource to use. We can set a constraint for each tran-

sition to allow ﬁltering links based on the users’ roles.

The associated hypermedia links are only delivered if

the constraint is fulﬁlled. We always deﬁne the max-

imum ε-NFA, but we can always omit individual sta-

tes if the permissions are not sufﬁcient. If some of the

state types are not wanted for certain resources, the

domain expert simply cannot model them and adapt

them to their wishes.

Based on these ε-NFAs, GUIs can be generated.

For this, we are taking advantage of the new standard

for web components (Cooney, 2014). Frontend de-

velopers are no longer responsible of implementing

REST by themselves. They no longer have to focus

on the correct behavior according to Fielding, they

can now focus on describing the web application as

an abstract model.

4 CHALLENGES

Since our research question is how RESTful Web Ap-

plications can be derived from ﬁnite-state machines,

we have to face different challenges. In order to solve

these challenges we try to take advantage of the bene-

ﬁts of the Web Components Standard (Cooney, 2014).

Therefore, we analyze resources which are the key

abstraction of information in RESTful Systems (Fiel-

ding, 2000).

Resources can have different representations that

consist of simple properties and links to other repre-

sentations (Richardson and Ruby, 2008). How can a

resource with its properties be graphically displayed

in a web interface? Established design patterns such

as the Master Detail View (Jovanovic, 2011) do not

provide a clear answer to this question. The master

list view can be represented by the GetCollectionRe-

source State Type. The detail view could then be re-

presented by a GetSingleResource State Type. The

Design Pattern, however, lacks the concept of input

masks that allow users to create or update a resource.

Furthermore, it remains unclear how the design pat-

tern could be used to easily link resources. So we

need to develop our own approach on how to map the

states of a RESTful API within a web application.

The exchange of resources between client and ser-

ver causes state transitions within the ε-NFA (Zuzak

et al., 2011). The client manages the current state of

the communication in its application state. During a

state transition, the server signals the next possible

Hypermedia: The Key to RESTful Web Applications

381

Table 1: An overview of functionalities offered by different state types. The column ‘Primary’ explains the functionalities on

the primary layer, whereas the column ‘Secondary’ explains the functionalities on the secondary layer.

State Types Primary Secondary

GetCollectionResource

Representation retrieval

of a collection of resources.

Retrieval of a collection of all linked or unlinked

subresources depending on the chosen mode

GetSingleResource

Representation retrieval

of a single resource

Retrieval of a single linked resource

PostResource Creation of a resource

Creation of a new resource including a link

to an existing resource

PutResource Update of a resource Creation of a link between two existing resources

DeleteResource Deletion of a resource Deletion of a link between two resources

transitions from which the client can select one. In or-

der to implement the hypermedia principle correctly

in the client, the web application must detect a transi-

tion within the hypermedia links of the response. Mo-

reover, the presence of such a link must be presented

to the user. This can be done by showing or hiding

buttons (Amundsen, 2017). For example, if the cur-

rently logged-in user is allowed to create a resource,

the server will emit a corresponding hypermedia link

in the response header. The hypermedia link leads to

the state for creating a resource. This will allow the

client to display a button for resource creation in the

GUI. The transitions determine the navigation con-

cept of the web application.

To generate executable applications automatically,

restrictions have to be made in order to give the gene-

rator a framework. A model-driven approach is more

effective if several related systems are to be develo-

ped that can be grouped together under one software

system family (V

olter et al., 2013).

A model-driven approach requires encapsulation

of the generic and domain-speciﬁc code sections of an

application. In object-oriented programming langua-

ges, class concepts are available that enable encapsu-

lation. This feature is easy to use to encapsulate rela-

ted code. In web development such constructs are not

available. Conventional JavaScript libraries provide

only limited support to outsource the code of a web

application into individual ﬁles (Haverbeke, 2011).

Although smaller JavaScript, HTML, and CSS ﬁles

can be created, this type of encapsulation is not desi-

rable for a model-driven approach. This concept does

not deﬁne what a reusable component might look like,

so it is not suitable for MDSD.

Recent web technologies are introducing

component-based approaches according to the Web

Components Standard (Cooney, 2014). This allows

code sections to be easily separated from application-

speciﬁc sections. However, we still do not know how

a model-driven architecture for web components can

be designed.

5 APPROACH

In order to generate RESTful Web Applications, we

need to commit to a ﬁxed architecture. Our approach

is based on the generic structure of RESTful APIs in-

troduced in Section 3. We assume that every state

of the ε-NFA is represented by a separate view in the

web application (Zuzak et al., 2011). In the following,

we clarify which views are to be created for the indivi-

dual states from Figure 1 on the basis of the Lecturer

Domain. We explain how RESTful Web Applications

should behave and propose our metamodel for descri-

bing their views. Finally, we give some insights into

the generator that creates web applications based on

Polymer web components.

5.1 Analysis of States

The s0 state in Figure 1 represents the dispatcher state

that embodies the entry point of the generated API.

The URL of the dispatcher state is the only one known

to the client. The dispatcher state uses transitions to

point to the next possible PrimaryGetCollection Sta-

tes and can be represented in the web application by

a navigation drawer menu that users use to navigate

between the PrimaryGetCollection States.

A PrimaryGetCollection State can be represented

by a ListView that displays a collection of resour-

ces. Each resource is represented by a CardView. In

the ListView, a button is displayed so that users can

navigate to an input mask to create new resources.

As already mentioned, a PrimaryPost State can be

mapped to an InputView within the web application.

It consists of input widgets that allow users to more

easily set the attribute values of the resource to be cre-

ated. Depending on the attribute type, different wid-

gets must be provided. The attribute type has to be

deﬁned by using the metamodel.

A PrimaryGetSingle State is represented by a

DetailView that is displayed after the user clic-

ked on a CardView within the ListView. In the

APMDWE 2018 - 3rd International Special Session on Advanced practices in Model-Driven Web Engineering

382

View

ResourceAttribute

InputResourceAttribute

InputView

DropdownMenuAttributeInputFieldAttribute

DateAttribute

HypermediaAttribute

DisplayResourceAttribute

TextAttribute

DetailViewCardView

ResourceViewAttribute

SingleResourceAttribute GroupedResourceAttribute

Figure 2: Simpliﬁed version of our metamodel as UML class diagram.

DetailView, the attribute values of the resource are

also displayed differently depending on the attribute

type. A date must be displayed in the correct for-

mat, while a hypermedia link must be displayed as

a clickable link. Again, the attribute types must be

modeled by using the metamodel.

The corresponding web interface of PrimaryPut

States is similar to the InputView for creating a new

resource. However, all widgets are preallocated with

the resource’s current attribute values. The user can

then just change the attributes that need to be updated.

We do not provide additional views for Primary-

Delete States in the web application, since a generic

dialog is sufﬁcient here. This dialog asks for the users

conﬁrmation to delete the resource.

A SecondaryGetCollection State is represented by

a ListView that displays all linked subresources of

a resource. This view can only be reached after the

main resource was requested from the PrimaryGet-

Single State. Table 1 shows that the states located

at the secondary level provide functionality for lin-

king and unlinking resources. To simplify the linking

or unlinking of resources, the ListView has two dif-

ferent modes: In the OnlyLinkedSubresources mode,

the ListView displays all linked subresources. The

second mode is the AllPossibleSubresources mode,

which displays all resources that are already linked

and the ones that can be linked. Each CardView dis-

plays a check box so that subresources can be easily

linked or unlinked from the main resource.

SecondaryPut States are embodied by

InputViews that are used to update the subre-

source and establish a link to the main resource.

SecondaryPost States are also represented by

InputViews. These enable the creation of a subre-

source that will be automatically linked to the main

resource.

Clicking on a CardView within the ListView

opens the DetailView of the resource. This view is

identical to the view of PrimaryGetSingle States.

A generic delete dialog can also be used to repre-

sent SecondaryDelete States. This state offers functi-

onalities to remove a link to the main resource. The

subresource itself will not be deleted.

The analysis of the different states shows that

four different views are required: CardViews, Detail-

Views, InputViews, and ListViews, that are repre-

sented by a list of CardViews. Now we want to pre-

sent our understanding of how RESTful Web Appli-

cations should behave. The ListViews that represent

our PrimaryGetCollection States can display a button

that can be used to navigate to a POST InputView.

Due to the hypermedia constraint this button may only

be displayed under the following conditions:

• The ε-NFA includes a transition to a correspon-

ding PrimaryPost State, which offers the POST

functionality.

• The client receives a link in the response header

that contains the POST URL.

The web application is responsible to analyze the

response link headers to determine if the server allows

the transition to the PrimaryPost State. If the server

does not allow the creation of a resource, the POST

button must not be displayed to the user. Therefore,

the implementation of the hypermedia constraint re-

Hypermedia: The Key to RESTful Web Applications

383

quires a ﬁxed structure of the ε-NFA. The web appli-

cation uses the provided link headers to decide if the

navigation buttons must be presented to the user. This

behavior is what we consider as a RESTful Web Ap-

plication.

Now that we have determined how a ε-NFA af-

fects a RESTful Web Application, we will present our

metamodel.

5.2 Metamodel

By using the metamodel domain experts can describe

each view of a web application at a higher abstraction

level. This metamodel can be processed by a software

generator to create functional web applications. The

key abstraction of information in REST is a resource

that has attributes in the form of key-value pairs (Fiel-

ding, 2000). Because values of attributes are shown

to the user, domain experts must use the metamodel

to deﬁne how these values should be represented.

We examined GUIs from a non-technical per-

spective to keep the metamodel generic. Because of

this, other generators can use this metamodel to create

client applications based on other frontend technolo-

gies.

The easiest way to represent a resource in a view

is to arrange its attributes vertically one by one. For

this reason, a vertical layout is used in our views. In

CardViews and DetailViews it may be necessary

to display attributes horizontally next to each other.

This is the case if the full name of a lecturer con-

sists of the academic title, ﬁrst name, and surname.

In InputViews the possibility of a horizontal arran-

gement should be denied, since otherwise rendering

problems may occur on mobile devices. These often

have smaller screens and are therefore not suitable for

horizontal arrangements of input widgets.

The order in which the attributes are arranged can

be determined by the domain expert. In addition, they

can use the metamodel to deﬁne which font size and

color should be applied to the attribute values. Figure

2 shows a simpliﬁed version of our metamodel.

The metamodel deﬁnes how the attributes of a re-

source should be graphically displayed in the inter-

face. For this reason, we start by explaining the class

ResourceAttribute. This represents an attribute of

a resource in the metamodel.

In the metamodel, we distinguish bet-

ween attributes that can be read or written.

DisplayResourceAttributes represent the read-

only attributes, while InputResourceAttributes

represent the modiﬁable attributes. These two classes

serve as superclasses for speciﬁc attribute types,

which can be seen in the lowest level of the diagram

in Figure 2.

Depending on the attribute type, the attribute value

must be processed differently in the client application.

We provide some examples that show why different

attribute types are necessary:

• A ﬁrst name as text can be displayed directly as

a string. In the DetailView one would use a

TextAttribute. In the InputView one would

use an InputFieldAttribute.

• Hypermedia links must present a clickable link in

the GUI.

• Timestamps have to be converted into a human-

readable format.

These are just a few obvious examples of possible at-

tribute types. Our metamodel can easily be extended

by inheritance for additional attribute types.

A DisplayResourceAttribute can be wrapped

in a SingleResourceAttribute, informing the ge-

nerator that the attribute should occupy an entire

row within the vertical layout. If several attribu-

tes of a resource are to be displayed horizontally

next to each other, they must be grouped using a

GroupedResourceAttribute.

With the metamodel CardViews, DetailViews,

and InputViews can be described. The CardViews

are required within ListViews. Delete views

do not have to be generated separately be-

cause a generic delete dialog is sufﬁcient. The

CardViews and DetailViews have a collection

of ResourceAttributes, which represents the

content of each view. Since no input wid-

gets can be grouped horizontally in InputViews,

InputResourceAttributes cannot be grouped by

GroupedResourceAttributes.

The generator now has all the information nee-

ded to generate the views required by a RESTful Web

Application based on this metamodel. Each state of

the ε-NFA is mapped to a speciﬁc view description

with the exception of the delete states. For example,

a PUT state receives an instance of an InputView.

The collection InputResourceAttribute describes

the content of the input mask that has to be generated.

5.3 Generators

For the implementation of a model-driven approach,

Voelter et al. proposed to start developing a reference

implementation (V

olter et al., 2013). The reference

implementation, in our case, is a manually developed

web application that communicates with a RESTful

API. The API provides functionalities for managing

lecturers that work at a faculty. For each state of the

APMDWE 2018 - 3rd International Special Session on Advanced practices in Model-Driven Web Engineering

384

< template >

< abstract - card - v i e w

url ="[[ u rl ]]"

up d a t e_ r e l _t yp e ="updateLecturer"

de l e t e_ r e l _t yp e ="deleteLecturer" >

</ abstract - card - view >

</ template >

< s cript >

Pol y m er ( {

is : "lecturer- card - view " ,

pr o pe r ti e s : {

url : { t y p e : Strin g , value : "" }

} } );

</ s cript >

Listing 1: Excerpt from the ‘lecturer-card-view’ com-

ponent. The code highlighted in orange is domain-speciﬁc

information that is inserted from the metamodel into the

generator template (black).

ε-NFA, a separate view was implemented as descri-

bed in Section 5.1. The web application has imple-

mented all the required features needed in the genera-

ted web applications.

The next step is to analyze the code of the refe-

rence implementation more closely to identify the ge-

neric and domain-speciﬁc code sections. The generic

code is the same in all generated web applications.

To reuse this code, the generic code sections must

be separated into different components. The domain-

speciﬁc code is different in each project and therefore

must be generated by the generator using the meta-

model. We decided to use the Polymer library to se-

parate these two code sections. Polymer is based on

the concept of web components, whereby the neces-

sary separation of the code sections can be realized.

In the following, we explain how the two code

sections can be separated using the example of a

lecturer-card-view. The lecturer-card-view

represents a resource on a CardView within a

ListView. CardViews play an important role in our

navigation concept, as they provide buttons that al-

low the user to update or delete the resource. The

lecturer-card-view component requires the rela-

tion type for PUT and DELETE requests to imple-

ment the hypermedia constraint. Only then the client

can determine the URLs for updating and deleting the

resource. If the client ﬁnds the corresponding URLs

in the response link headers using this relation types,

the buttons have to be displayed.

We now form two components: the gene-

ric abstract-card-view and the domain-speciﬁc

lecturer-card-view. Our abstract-card-view

is the same in all web applications. Therefore, it can

be reused in every project. It contains the logic nee-

ded in every CardView. These include the following

functionalities:

• The network communication to request the re-

source from the server.

• The analysis of the response link headers to dis-

play the corresponding buttons.

• The navigation logic to the UpdateView or

DeleteView.

The domain-speciﬁc lecturer-card-view contains

all the information about how the attributes of the re-

source should be displayed. This component must

be generated because the information about the view

content is described in the metamodel.

Due to the necessary code separation, the generic

and domain-speciﬁc sections of the CardView were

separated into two different components. In order to

establish the communication between these two com-

ponents they must be properly nested. The nesting is

enabled by using the content tag offered by the Poly-

mer library. We illustrate this concept within Figure 3.

According to this approach, the domain-

speciﬁc lecturer-card-view encloses the

abstract-card-view component. The inner

component requires domain-speciﬁc information that

must be set by the outer components via its proper-

ties. The generated HTML code will be inserted

into the generic component by using the content tag.

Listing 1 shows that the generic component now has

all the information needed to request resources from

the server and present the resource to the user.

These concepts also apply to the other required

components, such as ListViews, DetailViews, and

InputViews. The generator iterates over the states of

the ε-NFA and generates the required components for

each state. The generated components are arranged by

the generator to create functional web applications.

6 DISCUSSION

At the beginning we summarized related work and

explained that modeling has a central role in soft-

ware development. Moreover, we showed that model-

driven approaches for developing frontends already

worked in the past. Afterwards, we introduced our

project and explained how to deﬁne RESTful Systems

as ε-NFAs. After having clariﬁed all challenges, we

presented our approach and outlined results.

To answer our ﬁrst research question Q1, we take

a look at the results of Section 5.1. In order to imple-

ment RESTful Web Applications we need four diffe-

rent views within our approach: CardViews, Detail-

Views, InputViews, and ListViews, that are repre-

sented by a list of CardViews. Moreover, the frontend

is responsible for analyzing the response link headers

Hypermedia: The Key to RESTful Web Applications

385

lecturer-card-view

abstract-card-view

Generated Code Generic Code

</content>

JavaScript logic

“updateLecturer”

“deleteLecturer”

Figure 3: This ﬁgure shows how the generator ﬁlls the missing information into our code templates. The ‘abstract-card-view’

contains all generic logic. Our generator generates the ‘lecturer-card-view’ and inserts the properties from the metamodel into

the generator template shown in Listing 1. The domain-speciﬁc information is transferred to the generic component by setting

its properties. The generic component can then access this information which will be required for the network communication.

to determine which buttons must be displayed. This

behavior fulﬁlls all six constraints of REST. Further-

more, the four views were sufﬁciant to describe all

requirements within our lecturer domain in our meta-

model.

The advantage of this abstraction into four diffe-

rent views is that new developers can be onboarded

fast. Nevertheless, it is not always trivial to divide

domain requirements into only four views. Suppor-

ting more views could be helpful and ease the deve-

lopment even further. Therefore, we need to inves-

tigate if additional views are supported by the REST

constraints.

The research questions Q2 and Q3 both focus

on supporting developers via a model-driven appro-

ach. Since ε-NFAs are easier to understand and easier

to deﬁne than implementing RESTful Systems from

scratch, our metamodel can reduce the development

efforts. Developers can easily deﬁne all hypermedia

aspects via the state transitions in our ε-NFA. They

do no longer require any knowledge on how to im-

plement the hypermedia constraint correctly. They

only need to know the hypermedia principle itself and

how to describe RESTful Systems as ε-NFA. We have

shown that viable web applications can be realized

with a model-driven approach. Especially within the

domain REST, the model-driven approach is suitable

because REST is very restrictive and repetitive. This

results in a high degree of reuse (Kelly and Tolvanen,

2008). Web components are also very well suited be-

cause the required encapsulation of the code is ena-

bled.

A disadvantage of our current metamodel is the

ﬁxed structure of our ε-NFAs. Nevertheless, we need

a ﬁxed structure in our model-driven approach in or-

der to generate web applications. Any change to the

ﬁxed structure would require all generators to be re-

written. The drawback is that our web application

cannot support every possible RESTful API which

is in conﬂict with Amundsen’s vision (Amundsen,

2017).

Another drawback is that the metamodel is cur-

rently very technical. Developers still have to under-

stand how to describe REST as ε-NFA, and our me-

tamodel could beneﬁt from further abstraction levels.

We already have initial approaches to create a higher

abstraction of our metamodel on the server-side (Ul-

samer et al., 2018). It would be interesting to explore

the possibility of abstraction levels for the description

of the client-side. A description in the form of featu-

res would be a possible higher level, so that develo-

pers only have to deﬁne which features are required.

Another issue is the complexity of the generated

web applications. We originally wanted to generate

reusable web components. Unfortunately our genera-

tor evolved and its complexity makes our components

difﬁcult to reuse. A next step would therefore be to

focus on reusable web components that can be parti-

ally used in other non-generated projects.

Finally, we have to deal with platform indepen-

dence. Currently, our generators have been developed

for Polymer 1.0. However, a lot has changed in ver-

sion 2.0, so the generators are difﬁcult to adapt. It re-

mains to be clariﬁed whether generators can be built

that can operate independently of the platform used.

APMDWE 2018 - 3rd International Special Session on Advanced practices in Model-Driven Web Engineering

386

REFERENCES

Amundsen, M. (2017). RESTful Web Clients: Enabling

Reuse Through Hypermedia. O’Reilly Media.

Beltramelli, T. (2017). pix2code: Generating Code from a

Graphical User Interface Screenshot. arXiv preprint

arXiv:1705.07962.

Bettini, L. (2013). Implementing Domain-Speciﬁc Langua-

ges with Xtext and Xtend. EBL-Schweitzer. Packt Pu-

blishing, Limited.

Cooney, D. (2014). Introduction to Web Components.

https://www.w3.org/TR/2014/NOTE-components-

intro-20140724/.

Darwen, H. and Date, C. J. (1995). The Third Manifesto.

SIGMOD Rec., 24(1):39–49.

Efftinge, S. (2014a). Xtend Documentation. http://www.

eclipse.org/xtend/documentation.html.

Efftinge, S. (2014b). Xtext Documentation. http://www.

eclipse.org/Xtext/documentation.html.

Evans, A. (2015). Polymer Project 1.0. https://www.

polymer-project.org/1.0/start/.

Fertig, T. and Braun, P. (2015). Model-driven Testing of

RESTful APIs. In Proceedings of the 24th Interna-

tional Conference on World Wide Web, WWW ’15

Companion, pages 1497–1502, New York, NY, USA.

ACM.

Fielding, R. (2000). REST: Architectural Styles and the De-

sign of Network-based Software Architectures. Doc-

toral dissertation, University of California, Irvine.

Fielding, R. (2008). REST APIs must be hyper-text

driven. http://roy.gbiv.com/untangled/2008/rest-apis-

must-be-hypertext-driven.

Fowler, M. (2010). Domain-Speciﬁc Languages. Addison-

Wesley Signature Series (Fowler). Pearson Education.

Haverbeke, M. (2011). Eloquent JavaScript: A Modern In-

troduction to Programming. No Starch Press Series.

No Starch Press.

Jaber, M., Falcone, Y., Dak-Al-Bab, K., Abou-Jaoudeh, J.,

and El-Katerji, M. (2018). A high-level modeling lan-

guage for the efﬁcient design, implementation, and

testing of Android applications. International Journal

on Software Tools for Technology Transfer, 20(1):1–

18.

Jacobson, I. (1992). Object-oriented Software Engineer-

ing: A Use Case Driven Approach. ACM Press Series.

ACM Press.

Jakob, M., Schiller, O., Schwarz, H., and Kaiser, F. (2007).

ﬂashWeb: Graphical Modeling of Web Applications

for Data Management. In Tutorials, Posters, Panels

and Industrial Contributions at the 26th International

Conference on Conceptual Modeling - Volume 83, ER

’07, pages 59–64, Darlinghurst, Australia, Australia.

Australian Computer Society, Inc.

Jovanovic, J. (2011). Designing User Interfaces For Bu-

siness Web Applications. Professional Web Design:

The Best of Smashing Magazine, 1:89–108.

Kelly, S. and Tolvanen, J. (2008). Domain-Speciﬁc Mo-

deling: Enabling Full Code Generation. Wiley -

IEEE. Wiley.

Richardson, C., Rymer, J. R., Mines, C., Cullen, A., and

Whittaker, D. (2014). New Development Platforms

Emerge For Customer-Facing Applications: Firms

Choose Low-Code Alternatives For Fast, Continuous,

And Test-And-Learn Delivery. https://www.forrester.

com/report/New+Development+Platforms+Emerge+

For+CustomerFacing+Applications/-/E-RES113411.

Richardson, L. and Ruby, S. (2008). RESTful Web Services.

O’Reilly Media.

Schreibmann, V. and Braun, P. (2015). Model-Driven Deve-

lopment of RESTful APIs. In Proceedings of the 11th

International Conference of Web Information Systems

and Technologies, pages 5–14. INSTICC, SciTePress.

Shimomura, T., Takahashi, M., Ikeda, K., and Mogami, Y.

(2003). Web application generator by image-oriented

design. SIGSOFT Softw. Eng. Notes, 28(2):14–.

Ulsamer, P., Fertig, T., and Braun, P. (2018). Feature-

oriented Domain-speciﬁc Languages. In Riebisch, M.,

Huhn, M., Hungar, H., and Voss, S., editors, Dagstuhl-

Workshop MBEES: Modellbasierte Entwicklung ein-

gebetteter Systeme XIV, Schloss Dagstuhl, Germany,

2018, Tagungsband Modellbasierte Entwicklung ein-

gebetteter Systeme, pages 31–40. fortiss GmbH,

unchen.

olter, M., Stahl, T., Bettin, J., Haase, A., Helsen, S., Czar-

necki, K., and von Stockﬂeth, B. (2013). Model-

Driven Software Development: Technology, Engineer-

ing, Management. Wiley Software Patterns Series.

Wiley.

Vu, H., Fertig, T., and Braun, P. (2017). Towards Model-

driven Hypermedia Testing for RESTful Systems. In

Proceedings of the 13th International Conference on

Web Information Systems and Technologies - Volume

1: WEBIST,, pages 340–343. INSTICC, SciTePress.

Webber, J., Parastatidis, S., and Robinson, I. (2010). REST

in Practice: Hypermedia and Systems Architecture.

Theory in practice series. O’Reilly Media.

Zuzak, I., Budiselic, I., and Delac, G. (2011). Web Engi-

neering: 11th International Conference, ICWE 2011,

Paphos, Cyprus, June 20-24, 2011, chapter Formal

Modeling of RESTful Systems Using Finite-State Ma-

chines, pages 346–360. Springer Berlin Heidelberg.

Hypermedia: The Key to RESTful Web Applications

387