RESTful Mobile Application for Android : Mobile Version of Inspectera Online

(1)

Department of Computer and Information Science

Master’s thesis

RESTful Mobile Application for Android:

Mobile Version of Inspectera Online

by

Sheikh Ali Arman

LIU-IDA/LITH-EX-A--14/002—SE

2014-01-22

Linköpings universitet

(2)

(3)

iii

Institutionen för Datavetenskap

Department of Computer and Information Science

Master’s thesis

RESTful Mobile Application for Android:

Mobile Version of Inspectera Online

by

Sheikh Ali Arman

LIU-IDA/LITH-EX-A--14/002—SE

2014-01-22

Examiner: Prof. Kristian Sandahl

Dept. of Computer and Information Science,

Linköping University, Sweden.

Supervisor: Ivan Ukhov

Dept. of Computer and Information Science,

Linköping University, Sweden.

(4)

(5)

v

(6)

(7)

vii

Abstract

Web service-based mobile applications have become emergent in the recent

years. Representational State Transfer (REST) architecture style

introduced the concept of Resource Oriented Architecture (ROA), which

has been widely used for building applications for all platforms. This

master’s thesis designs and develops a Web service-based mobile

application for Android platform following the constraints of REST

architectural style. It also proposes an authentication model for RESTful

applications. The master’s thesis is completed at the company Inspectera

HK AB in Norrköping, Sweden. The developed application is called the

“Mobile version of Inspectera Online.”

Keywords: REST, ROA, RPC, SOAP, SOA, Android, mobile application,

Inspectera Online, RESTful authentication.

(8)

(9)

ix

Acknowledgements

I would like to thank Professor Kristian Sandahl for inspiring me to

pursue my research interest. I thank him for his patience, guidance and

support, without which this work could not be completed.

I would like to thank my supervisor, Ivan Ukhov, for his advice and

feedback, which undoubtedly contributed to my success.

Last but not least, I would like to thank Mr. Anders Ekeberg, CEO of

Inspectera HK AB, for believing in my vision and giving me such a

wonderful thesis opportunity.

(10)

(11)

xi

1. Introduction ... 1

1.1#Background#...#1

#

1.2#Research#objectives#...#2

#

1.3#How#the#study#is#conducted#...#2

#

1.4#How#the#report#is#organized#...#3

#

2. SOAP ... 4

2.1#Overview#...#4

#

2.2#SOAP#messages#...#5

#

2.3#SOAP#envelope#...#5

#

2.4#SOAP#header#...#6

#

2.5#SOAP#body#...#7

#

2.6#SOAP#fault#...#7

#

2.7#SOAP#communication#model#...#8

#

2.7.1 RPC style communication#...#8

#

2.7.2 Document/message style communication#...#9

#

2.8#SOAP#via#HTTP#...#10

#

3. REST ... 13

3.1#Overview#...#13

#

3.2#Resource#...#14

#

3.3#Representation#...#14

#

3.4#Stateless#interactions#and#self#descriptive#messages#...#15

#

3.5#Uniform#interface#...#16

#

3.5.1 GET/RETRIEVE operation#...#17

#

3.5.2 PUT/CREATE operation#...#18

#

3.5.3 POST/UPDATE operation#...#19

#

3.5.4 DELETE/DELETE operation#...#20

#

3.6#Richardson’s#Maturity#Model#(RMM)#...#21

#

3.6.1 RMM Level 0#...#21

#

3.6.2 RMM Level 1#...#22

#

3.6.3 RMM Level 2#...#22

#

3.6.4 RMM Level 3#...#22

#

4. REST vs SOAP ... 25

4.1#Background#of#study#...#25

#

4.2#Comparative#analysis#...#25

#

4.2.1 Scalability#...#25

#

4.2.2 Coupling#...#27

#

4.2.3 Security#...#27

#

4.2.4 Performance#...#28

#

4.2.5 Protocol transparency and independence#...#29

#

4.2.6 Service discovery#...#29

#

4.3#Empirical#studies#...#29

#

4.4#Decision#in#favor#of#REST#...#31

#

5. System overview ... 32

5.1#Inspectera#Online#...#32

#

5.2#Mobile#version#of#Inspectera#Online#(IOVMobile)#...#33

#

(12)

xii

5.4$Functionalities$and$interface$design$...$39

$

5.4.1 Login and main menu$...$39

$

5.4.2 Inspections/Controls$...$41

$

5.4.3 Search inspections$...$46

$

5.4.4 Inspection photo evidence$...$46

$

5.4.5 News$...$48

$

5.4.6 Maps$...$48

$

6. IO-Mobile architecture ... 50

6.1$Architecture$overview$...$50

$

6.2$IOEMobile$architecture$...$51

$

6.3$IOEMobile$layers$...$52

$

6.3.1 Presentation layer$...$52

$

6.3.2 Business logic layer$...$53

$

6.3.3 Data access layer$...$53

$

6.4$IOEMobile$packages$...$54

$

6.4.1 io.mobile.applogic$...$54

$

6.4.2 io.mobile.uilogic$...$55

$

6.4.3 io.mobile.comm$...$56

$

6.4.4 io.mobile.model$...$57

$

6.4.5 io.mobile.ui$...$57

$

6.4.6 io.mobile.ui.builder, io.mobile.ui.builder.criterion$...$57

$

6.4.7 io.mobile.exceptions$...$57

$

6.5$IOEMobile$operations$...$58

$

7. RESTful Web API ... 62

7.1$Overview$...$62

$

7.2$Resources,$URIs$and$HTTP$methods$...$62

$

7.2$Design$and$implementation$...$64

$

7.3$RESTful$Web$API$samples$...$65

$

7.3.1 Instrumentation for sampling$...$65

$

7.3.2 Control resource$...$66

$

7.3.3 Routine resource$...$72

$

7.3.4 ControlPhoto resource$...$73

$

7.3.5 Map resource$...$75

$

7.3.6 News resource$...$76

$

7.3.7 Unit resource$...$80

$

7.3.8 User resource$...$82

$

7.4$Deployment$...$83

$

8. REST Compliance ... 84

8.1$Conformance$to$REST$constraints$...$84

$

8.2$HATEOAS$implementation$...$86

$

8.3$RESTful$security$and$authentication$...$92

$

8.4$RMM$Compliance$Level$...$94

$

8.4.1 Level 0 compliance$...$94

$

8.4.2 Level 1 compliance$...$95

$

8.4.3 Level 2 compliance$...$95

$

8.4.4 Level 3 compliance$...$95

$

9. Conclusions ... 96

(13)

xiii

Bibliography ... 99

Appendices ... 102

A. RESTful Web API code ... 103

A.1$$WebApiControlService.java$...$103

$

A.2$WebApiControlServiceImpl.java$...$103

$

A.3$WebApiMapService.java$...$113

$

A.4$WebApiMapServiceImpl.java$...$113

$

A.5$WebApiNewsService.java$...$116

$

A.6$WebApiNewsServiceImpl.java$...$116

$

A.7$WebApiUnitService.java$...$123

$

A.8$WebApiUnitServiceImpl.java$...$123

$

A.9$WebApiUserService.java$...$125

$

A.10$WebApiUserServiceImpl.java$...$125

$

A.11$WebApiUtil.java$...$127

$

A.12$WebApiSecurity.java$...$129

$

A.13$UriManager.java$...$131

$

A.14$Link.java$...$131

$

A.15$DataConverter.java$...$132

$

A.16$DataConverterImpl.java$...$132

$

B. IO-Mobile code ... 137

B.1$$se.inspectera.io.mobile.ui$...$137

$

B.1.1$$LoginActivity.java$...$137

$

B.1.2 ControlListActivity.java$...$141

$

B.1.3 ControlEditorActivity.java$...$146

$

B.2$$se.inspectera.io.mobile.uilogic$...$152

$

B.2.1 ControlsHelper.java$...$152

$

B.2.2 MapHelper.java$...$159

$

B.2.3 NewsHelper.java$...$161

$

B.2.4 UnitHelper.java$...$164

$

B.2.5$SecurityHelper.java$...$165

$

B.2.6 UriHelper.java$...$167

$

B.3$$se.inspectera.io.mobile.applogic$...$169

$

B.3.1 ControlsManager.java$...$169

$

B.3.2 ControlPhotoManager.java$...$172

$

B.3.3 RoutineManager.java$...$174

$

B.3.4 MapManager.java$...$174

$

B.3.5 NewsManager.java$...$175

$

B.3.6 UnitManager.java$...$178

$

B.3.7 UserManager.java$...$179

$

B.3.8 SecurityManager.java$...$179

$

B.4$$se.inspectera.io.mobile.comm$...$181

$

B.4.1 CommunicationManager.java$...$181

$

B.4.2 Request.java$...$186

$

B.4.3 GetRequest.java$...$187

$

B.4.4 PostRequest.java$...$189

$

B.4.5 PutRequest.java$...$192

$

B.4.6 DeleteRequest.java$...$192

$

(14)

xiv

Figure 2.1: Distributed messaging using SOAP [3:124].!...!4!

Figure 2.2: SOAP message structure described in UML [3:126].!...!5!

Figure 2.3: Usage of the SOAP HTTP POST method [3:141].!...!12!

Figure 3.1: RESTful Web services architecture [7].!...!16!

Figure 3.2: GET/RETRIEVE operation example [6:14].!...!17!

Figure 3.3: PUT/CREATE operation example [6:17].!...!18!

Figure 3.4: POST/UPDATE operation example [6:19].!...!19!

Figure 3.5: DELETE/DELETE operation example [6:20].!...!20!

Figure 3.6: Richardson's Maturity Model (RMM) for REST [10].!...!21!

Figure 5.1: Inspectera Online dashboard.!...!32!

Figure 5.2: IO-Mobile on Google play store.!...!33!

Figure 5.3: Use case diagram.!...!34!

Figure 5.4: Login screen.!...!39!

Figure 5.5: Main menu screen.!...!40!

Figure 5.6: Process steps for inspection category.!...!42!

Figure 5.7: Inspections grouped into a process step.!...!42!

Figure 5.8: Inspection editor for submitting inspection data.!...!43!

Figure 5.9: Inspection editor showing details of a completed inspection.!.!43!

Figure 5.10: Inspection editor dynamic UI example 1.!...!44!

Figure 5.11: Inspection editor dynamic UI example 2.!...!44!

Figure 5.12: Deviations from quality standards indicated.!...!45!

Figure 5.13: Follow up information in case of a deviation.!...!45!

Figure 5.14: Inspection list with colored deviation markers.!...!45!

Figure 5.15: Search operation.!...!46!

Figure 5.16: Search filters.!...!46!

Figure 5.17: Photo upload screen.!...!47!

Figure 5.18: Uploading evidence photo.!...!47!

Figure 5.19: Inspection with an evidence photo.!...!47!

Figure 5.20: Evidence photo displayed.!...!47!

Figure 5.21: Company news and notices.!...!48!

Figure 5.22: Posting news.!...!48!

Figure 5.23: List of maps.!...!49!

Figure 5.24: Map displayed.!...!49!

Figure 6.1: High-level architecture.!...!50!

Figure 6.2: IO-Mobile layered architecture.!...!51!

Figure 6.3: IO-Mobile package diagram.!...!52!

Figure 6.4: Class diagram of io.mobile.applogic.!...!54!

Figure 6.5: Class diagram of io.mobile.uilogic.!...!55!

Figure 6.6: Class diagram of io.mobile.comm.!...!56!

Figure 6.7: IO-Mobile state machine diagram.!...!59!

Figure 6.8: Controls state machine.!...!60!

(15)

xv

Figure 7.2: RESTful Web API deployed on Amazon EC2 server.!...!83!

Figure 8.1: Login information being submitted for User ‘arman’.!...!87!

Figure 8.2: Main menu screen of IO-Mobile.!...!90!

Figure 8.3: Control editor showing the Control specified in Listing 8.5.!....!91!

(16)

xvi

Table 3.1: CRUD operations associated to HTTP verbs [6].!...!17!

Table 6.1: HTTP methods for IO-Mobile CRUD operations.!...!58!

Table 7.1: Resource, URI and HTTP methods mapping.!...!64!

!

(17)

xvii

Listing 2.1: SOAP envelope structure [3:127].!...!6!

Listing 2.2: SOAP header example [3:129].!...!7!

Listing 2.3: Fault element example [2].!...!8!

Listing 2.4: Example of an RPC-style SOAP request [3:135].!...!8!

Listing 2.5: Example of an RPC-style response message [3:136].!...!9!

Listing 2.6: Example of a document style SOAP message [3:136].!...!10!

Listing 2.7: Sample HTTP/SOAP enveloped request [3:142].!...!11!

Listing 2.8: Sample HTTP/SOAP response [3:142].!...!11!

Listing 3.1: HATEAOS example – an Order entity [9:116-117].!...!23!

Listing 7.1: GET request for Control resource.!...!67!

Listing 7.2: Response for Control resource GET request.!...!68!

Listing 7.3: POST request for Control resource.!...!69!

Listing 7.4: Response for Control resource POST request.!...!70!

Listing 7.5: Control search GET request.!...!70!

Listing 7.6: Response for Control search GET request.!...!72!

Listing 7.7: GET request for Routine resource.!...!72!

Listing 7.8: Response for Routine resource GET request!...!72!

Listing 7.9: PUT request for Control-Photo resource.!...!73!

Listing 7.10: Response for Control-Photo PUT request.!...!74!

Listing 7.11: GET request for Control-Photo resource.!...!74!

Listing 7.12: Response for Control-Photo GET request.!...!74!

Listing 7.13: GET request for Map resource.!...!75!

Listing 7.14: Response for Map resource GET request.!...!75!

Listing 7.15: GET request for Map list.!...!76!

Listing 7.16: Response for Map list GET request.!...!76!

Listing 7.17: GET request for News resource.!...!77!

Listing 7.18: Response for News resource GET request.!...!77!

Listing 7.19: PUT request for News resource.!...!78!

Listing 7.20: Response for News resource PUT request.!...!78!

Listing 7.21: POST request for News resource.!...!78!

Listing 7.22: Response for News resource POST request.!...!79!

Listing 7.23: DELETE request for News resource.!...!79!

Listing 7.24: Response for News resource DELETE request.!...!79!

Listing 7.25: GET request for News list.!...!79!

Listing 7.26: Response for News list GET request.!...!80!

Listing 7.27: GET request for Unit resource.!...!81!

Listing 7.28: Response for Unit resource GET request.!...!82!

Listing 7.29: GET request for User resource.!...!82!

Listing 7.30: Response for User resource GET request.!...!83!

Listing 8.1: Initial URI defined in the CommunicationManager class.!...!87!

Listing 8.2: GET request for User ‘arman’.!...!88!

(18)

(19)

1

1 Introduction

1.1 Background

Mobile devices such as smartphones and digital tablets have become very

popular over the last few years. Millions of such devices are being sold

each year, and they are rapidly becoming the next major platform for

computing. With this growing trend, the demand for mobile applications

has increased significantly. Most public and private organizations offering

services through their websites are now releasing mobile applications with

similar functionalities corresponding to their websites. This phenomenon

has been appreciated greatly by general users. Today we can check

everything—from weather to bank balance—using applications running

on our mobile phones.

These mobile applications often use Web services in order to execute their

business logics. Web-based systems are now offering their functionalities

through Service Oriented Architecture (SOA), which is being consumed

and used by the corresponding mobile applications in order to perform

their necessary back-end operations. Pure SOA-based mobile applications

and mashup applications are also growing in number. There are many

technologies for implementing SOA, such as SOAP, REST, DCOM,

CORBA, Java RMI and WCF. Finding the technology and architecture

style most suitable for Web service-based mobile applications is a very

important research objective for the days ahead.

(20)

1.2 Research objectives

This master’s thesis is focused on the design and development of a Web

service-based

mobile

application

following

the

principles

of

Representational State Transfer (REST) architectural style. The

primary objective is to implement the REST architectural style correctly

and efficiently in order to achieve full REST compliance. Special emphasis

is put into making the mobile application modular and maintainable. The

experience obtained from this implementation will provide a guideline for

building RESTful mobile applications.

A secondary objective is to conduct a literature review on REST

architectural style, its benefits, limitations and comparison with other

prominent Web service technologies (e.g., SOAP). The outcome of the

literature review will help comment on the suitability of REST

architecture style for Web service-based mobile applications. ,

As an additional objective, a stateless RESTful authentication model is to

be implemented for the mobile application.

1.3 How the study is conducted

The study for this master’s thesis is conducted at the Swedish company

Inspectera HK AB located in Norrköping, Sweden. Inspectera HK AB is

an ISO-9001 certified company specialized in various quality and

regulatory inspections. The company provides its IT solutions and services

through a Web-based system called “Inspectera Online.”

At the beginning of the thesis, a literature review is conducted on

Representational State Transfer (REST) architecture style in order to

ascertain its applicability for building service-oriented mobile

applications. Then, a fully REST-compliant mobile application is designed

(21)

and developed. The mobile application is written in Java for Android

mobile operating system. The mobile application utilizes a set of RESTful

Web services, which is also built as part of the thesis work.

1.4 How the report is organized

The report begins with descriptive chapters on two most prominent

technologies for building Web service-based applications - namely SOAP

(Chapter 2: SOAP) and REST (Chapter 3 - REST). Chapter 4: REST

vs SOAP presents a comparative study between SOAP and REST. The

results obtained through the comparative study were the basis for

choosing REST architectural style for building the mobile application.

Chapter 5: System overview and Chapter 6: IO-Mobile architecture

present the design and implementation of the mobile application.

Chapter 7: RESTful Web API provides the details on the RESTful Web

services built for the mobile application. Chapter 8: REST compliance

explains how the implementation of the mobile application and the

RESTful Web services satisfy the constraints of REST architectural style.

Chapter 9: Conclusion makes conclusions based on the experience

obtained through the thesis work.

Since the developed mobile application will be used commercially, its

features and implementation will change rapidly in the production

environment. To facilitate readers’ understanding, appendices containing

relevant source code are included along with the thesis. Appendix A

contains the source code of the RESTful Web API and Appendix B

contains the source code of the mobile application. However, due to the

sheer size of the code and confidentiality, the entire source code cannot be

included. Only important parts of the implementation are made available

in the aforementioned appendices to establish clear understanding.

(22)

Chapter 2

2 SOAP

2.1 Overview

Simple Object Access Protocol or SOAP is a protocol specification designed

for the exchange of information in a distributed computing environment

[1]. The primary purpose of SOAP is to act as a messaging protocol

between Web services in a distributed system. SOAP uses XML and relies

heavily on the XML standards such as XML Schema and XML

Namespaces for its definition and function [2]. SOAP utilizes application

protocols such as HTTP, SMTP etc. for its message transmission.

Figure 2.1: Distributed messaging using SOAP [3:124].

The following sections provide brief overview of different parts of SOAP.

Detailed discussion of SOAP and its underlying mechanisms is beyond the

scope of this thesis.

(23)

2.2 SOAP messages

In SOAP, the communication process is carried out by the exchange of

SOAP messages. A SOAP message is packaged in an XML document

called an envelope [1][2][3]. The envelope has a predefined structure

following the SOAP specification [4]. It contains an optional header

element and a single mandatory body element [2][3]. The header element

contains information regarding how the message is going to be handled,

which includes the routing and delivery settings, authentication or

authorization assertions, transaction contexts etc. [2][3]. The actual

message, which is to be delivered and processed, is contained in the body

element.

Figure 2.2: SOAP message structure described in UML [3:126].

2.3 SOAP envelope

SOAP envelope wraps the XML payload for the SOAP request or response.

SOAP envelope is the single root of any SOAP message and is mandatory

for the message to be valid [1][3]. SOAP envelope can contain an optional

header element, and, if present, the header has to be the first sub-element

of the envelope [1][3]. The envelope must contain a body element. The

message payload will be transmitted in the body element.

(24)

<?xml version="1.0" encoding="UTF-‐8"?>

<env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-‐envelope"

env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<env:Header> <!-‐-‐ optional -‐-‐>

<!-‐-‐ header blocks go here . . . -‐-‐>

</env:Header>

<env:Body>

<!-‐-‐ payload or Fault element goes here . . . -‐-‐>

</env:Body>

</env:Envelope>

Listing 2.1: SOAP envelope structure [3:127].

2.4 SOAP header

The SOAP envelope may contain an optional header element. The header

element may contain child elements called the header blocks [1][2][3].

Each header block in the header element should have its own namespace

so that they can be identified and processed separately [3].

The purpose of the header element is to provide extensions to the message

without coupling them with the payload [3]. It allows the specification of

additional features such as security, transactions, object references, billing

and QoS attributes which can be added over time to SOAP messages

without breaking the specification [3:129]. It can also be used to provide

additional data to the Web services.

<env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-‐envelope" >

...

<env:Header>

<tx:transaction-‐id

xmlns:tx="http://www.transaction.com/transaction"

env:mustUnderstand="true">

512 </tx:transaction-‐id>

<notary:token xmlns:notary="http://www.notarization-‐

(25)

env:mustUnderstand="true">

GRAAL-‐5YF3

</notary:token>

</env:Header>

...

</env:Envelope>

Listing 2.2: SOAP header example [3:129].

2.5 SOAP body

The body element is the section in the envelope where the application

specific XML data are placed [3]. It is a mandatory element and must be

present in the envelope for it to be valid [1][2][3]. It may contain an

arbitrary number of child elements (i.e., body entries) [3]. However, each

of these body entries must be namespace qualified [3]. The body element

may contain either application specific data or a fault, but not both at the

same time [2][3]. Faults are discussed in the next section.

2.6 SOAP fault

A fault is a body element defined by the SOAP specification [4]. The

purpose of the fault is to send information about any errors occurred back

to the sender of the SOAP request [1][2]. A SOAP message may contain

only one fault element, which must be an immediate sub-element of the

body element [2][4].

<?xml version="1.0" encoding="UTF-‐8"?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-‐envelope">

<env:Body>

<env:Fault>

<faultcode>Client.Authentication</faultcode>

<faultstring>Invalid credentials</faultstring>

<faultactor>http://acme.com</faultactor>

<details>

<!-‐-‐ application specific details -‐-‐>

</details>

(26)

</env:Fault>

</env:Body>

</env:Envelope>

Listing 2.3: Fault element example [2].

2.7 SOAP communication model

SOAP supports two styles of communication, namely, the RPC style and

Document style [3:134].

2.7.1 RPC style communication

In RPC style communication, the client sends its request as a method call

with arguments. The response contains the return value of the method

call. RPC style supports automatic serialization/deserialization of

messages, allowing developers to express a request as a method call with

parameters, and receive the returned value as a response [3]. This is a

tightly coupled (synchronous) communication between the client and the

service provider [3].

<env:Envelope

xmlns:SOAP="http://www.w3.org/2003/05/soap-‐envelope"

xmlns:m="http://www.plastics_supply.com/product-‐prices">

<env:Header>

<tx:Transaction-‐id

xmlns:t="http://www.transaction.com/transactions"

env:mustUnderstand='1'>

512 </tx:Transaction-‐id>

</env:Header>

<env:Body>

<m:GetProductPrice>

<product-‐id>450R6OP</product-‐id>

</m:GetProductPrice>

</env:Body>

</env:Envelope>

Listing 2.4: Example of an RPC-style SOAP request [3:135].

(27)

<env:Envelope

xmlns:SOAP="http://www.w3.org/2003/05/soap-‐envelope"

xmlns:m="http://www.plastics_supply.com/product-‐prices">

<env:Header>

<-‐-‐! – Optional context information -‐-‐>

</env:Header>

<env:Body>

<m:GetProductPriceResponse>

<product-‐price>134.32</product-‐price>

</m:GetProductPriceResponse>

</env:Body>

</env:Envelope>

Listing 2.5: Example of an RPC-style response message [3:136].

2.7.2 Document/message style communication

Document style communication is message driven [3]. In the document

style communication, the SOAP body element contains an XML document

fragment corresponding to arbitrary application data and is well formed

against an XML schema and namespace external to the SOAP message

[3]. The content of the body element is received by the application as-is

and is used for further processing by its back-end logic. Listing 2.6

demonstrates a SOAP message in document style.

<env:Envelope

xmlns:SOAP="http://www.w3.org/2003/05/soap-‐envelope">

<env:Header>

<tx:Transaction-‐id

xmlns:t="http://www.transaction.com/transactions"

env:mustUnderstand='1'>

512 </tx:Transaction-‐id>

</env:Header>

<env:Body>

<po:PurchaseOrder xmlns:m="http://www.plastics_supply.com/POs"

orderDate="2004-‐12-‐02">

<po:from>

<po:accountName>RightPlastics</po:accountName>

<po:accountNumber>PSC-‐0343-‐02</po:accountNumber>

</po:from>

<po:to>

(28)

<po:supplierName>Plastic Supplies Inc.</po:supplierName>

<po:supplierAddress>Yara Valley Melbourne</po:supplierAddress>

</po:to>

<po:product>

<po:product-‐name>injection molder</po:product-‐name>

<po:product-‐model>G-‐100T</po:product-‐model>

<po:quantity>2</po:quantity>

</po:product>

</po:PurchaseOrder>

</env:Body>

</env:Envelope>

Listing 2.6: Example of a document style SOAP message [3:136].

2.8 SOAP via HTTP

SOAP uses XML as an encoding scheme for request and response

parameters, which can be transmitted through the Internet using HTTP

as a transport protocol without the need of any additional wrapping or

encoding [3]. The SOAP request is inserted into the body of an HTTP

POST request. The POST request is then transmitted through the

Internet to its intended service with the SOAP envelope as its data

payload. The HTTP POST request is then parsed, the SOAP request is

processed and a SOAP response is returned wrapped in an HTTP

response.

POST /PurchaseOrder HTTP/1.1

Host: http://www.plastics_supply.com <! – Service provider -‐-‐ >

Content-‐Type: application/soap+xml;

charset = "utf-‐8"

Content-‐Length: nnnn

<?xml version="1.0" ?>

<env:Envelope

xmlns:SOAP="http://www.w3.org/2003/05/soap-‐envelope"

xmlns:m="http://www.plastics_supply.com/product-‐prices">

<env:Header>

<tx:Transaction-‐id

xmlns:t="http://www.transaction.com/transactions"

env:mustUnderstand='1'>

512 </tx:Transaction-‐id>

(29)

</env:Header>

<env:Body>

<m:GetProductPrice>

<product-‐id>450R6OP</product-‐id>

</m:GetProductPrice>

</env:Body>

</env:Envelope>

Listing 2.7: Sample HTTP/SOAP enveloped request [3:142].

HTTP/1.1 200 OK

Content-‐Type:application/soap+xml;

charset = "utf-‐8"

Content-‐Length: nnnn

<?xml version="1.0" ?>

<env:Envelope

xmlns:SOAP="http://www.w3.org/2003/05/soap-‐envelope"

xmlns:m="http://www.plastics_supply.com/product-‐prices">

<env:Header>

<-‐-‐! – Optional context information -‐-‐>

</env:Header>

<env:Body>

<m:GetProductPriceResponse>

<product-‐price>134.32</product-‐price>

</m:GetProductPriceResponse>

</env:Body>

</env:Envelope>

(30)

(31)

Chapter 3

3 REST

3.1 Overview

The term REST stands for Representational State Transfer. The

concept of REST was introduced by Roy T. Fielding in his Ph.D.

dissertation in 2000 [5]. Fielding contributed to the development of HTTP

1.0 and was the primary architect of HTTP 1.1 and the author of uniform

resource identifier (URI) generic syntax. Although REST is not an

architecture by itself, it is a set of constraints which, applied in design,

leads to a software architecture style [6]. These constraints, when applied

as a whole, emphasize scalability of component interactions, generality of

interfaces, independent deployment of components and intermediary

components to reduce interaction latency, enforce security, and

encapsulate legacy systems [5].

The following constraints define a RESTful system [7]:

1. Everything being resource.

2. Resource identification through URI.

3. Uniform interface.

4. Manipulation of resources through representations.

5. Self-descriptive messages.

6. Stateless interactions.

7. Hypermedia as the engine of application state.

In order to understand REST, it is necessary to understand resource,

representation and state within the context of REST.

(32)

3.2 Resource

In REST, resource is the key abstraction of information [5]. Any

information that can be named can be a resource [5]. For example: a

document, an image, a server-side object etc. A resource is a conceptual

mapping to a set of entities, not the entities themselves corresponding to

the mapping at any particular point in time [5]. Resources must be

addressable, which means they can be accessed and transferred between

clients and servers [6].

Although the resource mapping is unique, different requests for resources

can point to the same entity stored on the server side. For example, if the

last submitted news into the server was in 20

th

_{June, 2013, then the}

request for getting latest news and the last posted news on day 20

th

_June,

2013 will point to the same entity. According to the REST principles, each

of these resources (i.e., mappings) can be accessed directly and

independently, but they may point to the same data [6].

Resources in REST are uniquely identified by their URIs. URI stands for

Universal Resource Identifier, which can be considered as a combination

of Uniform Resource Locators (URL) and Universal Resource Names

(URN) [5:110]. REST requires that URI to a resource should not change

over time [5:110][6].

REST accomplishes this by defining a resource to be

the semantics of what the author intends to identify (conceptual mapping),

rather than the value corresponding to those semantics at the time the

reference is created [5:111].

3.3 Representation

Representation of a resource is the data or content sent back and forth

between the client and server [6]. Representation is, therefore, a temporal

instance of the actual data stored or transferred at any given point of

time. A representation consists of data, metadata describing the data and,

(33)

on occasion, metadata to describe the metadata (usually for the purpose of

verifying message integrity) [5].

Due to the variety of client types and their content capability, the

representation of a resource can take various forms such as HTML, image,

file, plain text, XML and JSON etc. [6]. The data format of a

representation is known as a media type [5], which is generally denoted as

MIME type [8]. Based on the request of the client, its preferred format or

the nature of the resource itself, a resource will have appropriate

representation selected dynamically [5] (i.e., HTML, XML, JSON etc.). But

all of these different representations of a resource must be available

through the same resource identifier (i.e., URI) [5][6]. Appropriate format

for representation will be selected based on the client’s preference,

capability and the nature of the resource, but the resource will be accessed

through the same URI [5][6].

3.4 Stateless interactions and self descriptive messages

According to the REST principles, all communication between the client

and server must be stateless in nature [5:78]. Which implies that each

request from client to server must contain all of the information necessary

to understand and process the request [5]. No state information is kept on

the server and it is not allowed to use any stored context on the server or

imply information from previous requests [5][7]. Thus, the session state

information is maintained entirely on the client [5:79].

It is important to note that session or application state is different from

the resource state. Resource state contains information about resources

and is kept and maintained by the server [7].

(34)

3.5 Uniform interface

In modern Web-based applications, the basic operations can be categorized

into the following four types: Create, Retrieve, Update and Delete

(CRUD). RESTful applications allow manipulation of the state of its

resources through Web services and these manipulations are mainly

resource creation, modification, update and deletion [6]. Although

RESTful services can allow the execution of logic at the server level [6],

the resultant operations will take form of any of these four types of

operations.

Although HTTP supports a variety of verbs (or HTTP methods) such as

GET, POST, PUT, DELETE, OPTIONS, HEAD, TRACE, CONNECT and

PATCH, only a subset of these is usually enough to satisfy the

requirements of many distributed applications [9:11]. Thus, considering

REST and its underlying concept of resource and its representations, the

CRUD operations can be sufficiently mapped to the HTTP methods PUT,

GET, POST and DELETE [6][9].

HTTP GET is used to obtain a resource representation, HTTP DELETE is

used to remove a resource representation, HTTP PUT is used to create a

resource representation and HTTP POST is used to update a resource

representation [6][9]. The resource is identified by its URI and the

operation on the resource is denoted by the HTTP method used [6][9].

Figure 3.1: RESTful Web services architecture [7].

(35)

Data Action

HTTP protocol equivalent

CREATE

PUT

RETRIEVE

GET

UPDATE

POST

DELETE

Table 3.1: CRUD operations associated to HTTP verbs [6].

3.5.1 GET/RETRIEVE operation

HTTP GET method is used to retrieve a resource [6][9]. It is a read only

operation and making changes to the resource is not allowed. Figure 3.2

shows the mechanism with a sequence diagram [6:14]:

Figure 3.2: GET/RETRIEVE operation example [6:14].

In this example, the Java client sends an HTTP GET request for the

resource identified as Jane. The client also informs the server about its

(36)

preferred representation format as XML through the Accept request

header field. The server processes the request through its back-end and

sends the response containing the requested representation, i.e., the

student Jane entity serialized as XML

3.5.2 PUT/CREATE operation

HTTP method PUT is used to create a resource [6][9]. Figure 3.3

demonstrates the mechanism [6:17]:

Figure 3.3: PUT/CREATE operation example [6:17].

Here, the Java client wants to create an entity Jane. It submits an HTTP

PUT request to the server with the entity serialized as XML and included

into the payload. After receiving the request, the server identifies the

desired operation from the HTTP method and the payload format from the

(37)

back-end functions in order to perform the create operation. A response is

sent to the client notifying success or failure of the operation.

3.5.3 POST/UPDATE operation

HTTP method POST is used to update resources [6][9]. Figure 3.4 shows

the mechanism with a sequence diagram [6:19]:

Figure 3.4: POST/UPDATE operation example [6:19].

Java client submits a POST request to update the resource Jane. It should

be noted that an instance of Jane was previously acquired with the help of

a GET operation. After making changes on the previous Jane instance,

now the client is attempting to update it on the server. The changed

instance of Jane is thus serialized, included into the payload of the POST

request and submitted to the server. The server, after receiving the

request, extracts and de-serializes the changed Jane instance and then

(38)

uses its back-end functions to perform the update operation. A response is

sent to the client notifying success or failure of the operation.

3.5.4 DELETE/DELETE operation

HTTP method DELETE is used to delete resources [6][9]. The resources

are identified by the URI. The following example demonstrates the

mechanism [6:20]:

Figure 3.5: DELETE/DELETE operation example [6:20].

The Java client submits a DELETE request to the server in order to delete

the resource uniquely identified as Jane (i.e., the name Jane is the

resource identifier in this example). The server processes the request and

understands the desired operation by the HTTP method used. It identifies

the resource to be deleted by the URI of the request. It then performs the

delete operation utilizing its back-end functions. A response is sent to the

client notifying success or failure of the operation.

(39)

3.6 Richardson’s Maturity Model (RMM)

Leonard Richardson introduced a maturity model for REST in 2008

[9][10][11][12]. It provides 3 levels of REST compliance (Level 1-3) and a

level 0 for RPC-style interface [9][10][11][12]. The RMM levels can be

summarized as following:

Figure 3.6: Richardson's Maturity Model (RMM) for REST [10].

3.6.1 RMM Level 0

Level 0 is characterized by services having a single URI and the use of

single HTTP method (typically POST) [9]. This is based on RPC-style and

HTTP is basically used as a transport system or tunneling mechanism

without using any of the mechanisms of the Web [11]. This is also referred

to as Plain Old XML (POX) style which is quite similar to SOAP, only

without the SOAP envelop [9][11].

(40)

3.6.2 RMM Level 1

At level 1 maturity, many URIs per resource are employed but only one

HTTP verb is used [9][11][12]. Therefore, the main difference is that at

level 1 services expose numerous logical resources while at level 0 services

tunnel all interactions through a single large complex resource [9].

Operations at level 1 are carried out by inserting operation names and

parameters into a URI and calling the remote service using that URI with

only one HTTP method (typically via HTTP GET) [9].

According to Richardson [12], most services claiming to be RESTful today

are in reality at level 1. Level 1 can also be considered useful to some

extent as it provides some compliance to the REST principles [9].

3.6.3 RMM Level 2

At level 2, many URI-addressable resources are employed and services

support several HTTP verbs [9][11][12]. CRUD operations are supported

by the use of HTTP verbs such as POST, GET, PUT and DELETE [9][12].

Services use HTTP verbs and status codes to coordinate interactions and,

thus, level 2 attempts to gain the robustness of the Web [9].

3.6.4 RMM Level 3

Level 3 implements the concept of Hypermedia As The Engine Of

Application State (HATEAOS) [9][11][12]. In HATEAOS, resource

representations contain URI links to other resources which are relevant to

the current resource and might be of interest to the service consumer [9].

The service tells the consumer what can be done next and the

URI of the

resource needed to do so [11]. Thus, t

he service leads consumers through a

trail of resources, causing application state transitions as a result [9].

The main benefit of HATEAOS is that it decouples the server from the

client and allows the server to change the URI scheme in the services

(41)

without breaking client’s implementation [11]. The clients will look up the

state transitions from the services so their operational code does not have

to change.

Listing 3.1 demonstrates how an Order entity can be represented with

Hypermedia controls [9:116-117].

<order

xmlns:dap="http://schemas.restbucks.com/dap"

xmlns="http://schemas.restbucks.com" >

<dap:link

rel="self"

uri="http://restbucks.com/order/1234" />

<dap:link

rel="http://relations.restbucks.com/cancel"

uri="http://restbucks.com/order/1234" />

<dap:link

mediaType="application/vnd.restbucks+xml"

rel="http://relations.restbucks.com/payment"

uri="http://restbucks.com/payment/1234" />

<dap:link

mediaType="application/vnd.restbucks+xml"

rel="http://relations.restbucks.com/update"

uri="http://restbucks.com/order/1234" />

<item>

<milk>semi</milk>

<size>large</size>

<drink>cappuccino</drink>

</item>

<location>takeAway</location>

<cost>2.0</cost>

<status>unpaid</status>

</order>

Listing 3.1: HATEAOS example – an Order entity [9:116-117].

The link elements represent the next available states or operations

relevant to the Order entity. Using the link elements the client will be

able to move to the next states such as payment, update or cancellation of

(42)

order as necessary. The links are created and updated by the server.

Consequently, the server can change its addressing scheme anytime

without breaking the client’s implementation.

The uri attribute of the link element will contain the URI of the resource

with which the client can interact to progress towards the next state [9].

The rel attribute will contain the semantic markup [9]. The link element

will contain a mediaType attribute whenever the request requires an

entity body [9]. The mediaType attribute will declare the format of the

request payload [9] which should generally correspond to a MIME type

format. However, vendor or application specific formats are preferred as

demonstrated in the example [9]. If the request does not require an entity

body, the mediaType attribute will be absent [9:116].

Level 3 maturity indicates full compliance to REST principles. However, it

is very difficult to achieve. Being an emergent technology, there is no

absolute standard on how to represent hypermedia controls [11]. Also,

there is a lack of tool support as most modern development frameworks do

not have HATEAOS principles in their APIs. Most implementations of

HATEAOS found are research and development prototypes that need

industry usage and approval.

(43)

Chapter 4

4 REST vs SOAP

4.1 Background of study

During the design phase, two prominent Web service technologies – REST

and SOAP were evaluated in order to choose a technology most suitable

for building IO-Mobile. Although REST has gained significant popularity

in the recent years, SOAP is a defined, standardised and

well-supported technology. It can be considered as one of the representative

technologies for Remote Procedure Call (RPC) architectural style.

There is a longstanding debate in developer and scientific communities

about the proposed benefits of REST versus SOAP. REST is not a software

architecture but an architecture style. REST should be compared to RPC

architecture style, not a single technology such as SOAP. However, for the

purpose of making an educated decision about the right technology and its

possible benefits, a comparison between SOAP and REST is performed

based on published literature and scientific materials in this area. A

literature review on relevant performance studies involving SOAP and

REST is also included in Section 4.2.

4.2 Comparative analysis

4.2.1 Scalability

In RPC style architecture, different Web services have different interfaces

– each having its own semantics and operating parameters [7][14]. Clients

communicating with SOAP Web services must know the definitions and

(44)

semantics of the interface contracts [7][14]. Although it may not be

troublesome for small scale applications, but in a large open distributed

environment, where hundreds of Web services are employed having

numerous operations, this approach may pose significant problems due to

tight coupling and interface complexity and prevent large distributed

systems from reaching Web-scale scalability [7].

Because of the uniform interface constraint of REST, all resources

explosed have the same interface to the client [6][7][9]. REST keeps the

interface the same and selects the operations on the resource based on the

HTTP method used. For example, HTTP method GET is used for reading,

PUT for creating, DELETE to removing and POST for updating resource

representations, while keeping the interface unchanged in all cases. The

client only needs to understand the service specific data contract [14]. The

uniform interface constraint thus decouples the server from the client and

allows each of them to evolve independently [7]. Server and client

implementations can be changed indefinitely as long as the interface itself

remains unchanged. Hence, more emphasis can be placed on the resource

representations (i.e., the data) instead of the client-server interfacing [7].

Thus, REST increases the scalability of distributed systems considerably.

Due to the stateless interaction constraint of REST, all requests from the

client to the server must be stateless and should contain all necessary

information to understand and process the request [6][9]. Since the state

information is stored on the client side, the server does not have to

synchronize state information with client every time it is scaled up or load

balanced [7]. It removes the need for additional state management efforts

such as state servers, duplication of state data and shared memory, and

makes the server more scalable [7].

(45)

4.2.2 Coupling

In RPC style architecture, service contracts not only define the interfaces

but also the data formats used in interactions [7]. In SOAP, the data

format is defined in the WSDL using XML schema. This binding of

interface and data contract is convenient for code generation [7][14]. Any

change in the data types used in the services will force all clients to be

recompiled thus making the client and the server tightly coupled [7].

In REST, resources are manipulated through numerous representations.

The formats of such representations (i.e., HTML, XML, JSON, text,

images etc.) can vary based on the content negotition between the client

and the server. Data transmission takes place though HTTP messages

where the content-type and accept headers can indicate the server’s data

payload-type and what type of data the client is ready to receive [14][15].

By allowing this choice for data format, REST reduces coupling. REST

uses common data formats identified by the MIME types (such as

text/html, text/xml, application/json etc.). Thus, by adopting MIME as the

unified data format standard, REST eliminates ambiguity about data

format definitions [7] and reduces coupling [15].

4.2.3 Security

SOAP uses HTTP as a tunneling protocol [18:808][7]. SOAP messages are

generally wrapped into HTTP envelops and transmitted using HTTP

POST and therefore, can easily pass the firewall using port 80 [7]. This

introduces security risks as the real intention of the SOAP message is

hidden inside and cannot be understood without parsing. If the message

contains malicious request, it cannot be detected by the firewall without

additional protocol filtering [7].

REST exposes each resource with a unique URI and allows manipulation

using different HTTP methods. Each HTTP method has a clear meaning.

(46)

It is possible to deny operations by denying the URI or specific HTTP

methods. For example, if a certain resource should not be exposed, the

URI can be withheld. If a resource is read only, only HTTP GET method

can be allowed. If a resource can be removed, the HTTP DELETE method

can be allowed. The four operations (CRUD) on any resource can easily be

configured with appropriate security policies on the firewall and, thus, it

is much easier to implement and enforce security with REST [7].

4.2.4 Performance

REST is simple and utilizes existing standards widely used in the Web [7].

REST uses HTTP protocol directly for data transfer, therefore, the

performance drain due to the parsing and packaging SOAP messages is

avoided on both sides of the client and the server [7]. SOAP messages are

heavier in content than those of REST [7][16]. SOAP message payloads

are included within additional SOAP evelope XML tags and SOAP related

HTTP headers [16]. The simplest of operations such as deleting an entity

can be accomplished in REST by using the correct resource URI and HTTP

method DELETE, without requiring any additonal content body. However,

the SOAP counterpart would require SOAP specific additonal XML

payload. SOAP thus performs poorly in terms of network latency and

packet size against REST [16]. Section 4.2 of this report contains relevant

empirical studies confirming this phenomenon.

REST recommends responses to be cached in order to avoid unnecessary

operations which improves performance. Also, the ability to choose more

lightweight messaging format than XML such as the JavaScript Object

Notation or JSON [17] allows REST to achieve more optimal performance

[18]. Amazon.com, who provides its services using both REST and SOAP,

claims that its REST based services run six times faster than the SOAP

based services [7][13].

(47)

4.2.5 Protocol transparency and independence

With SOAP, the same message in the same format can be transported

across a variety of middleware systems using different transport protocols

in addition to HTTP such as TCP, SMTP and JMS [18][19][20]. Moreover,

the transport protocol may change along the way [18]. Using SOAP

headers, security and quality of service (QoS) aspects such as encryption

and reliable transfer can be configured independent of the underlying

transports used [18]. Thus, SOAP gains protocol transparency and

independence [18] while REST only attains its true potential through

HTTP.

4.2.6 Service discovery

SOAP services are registered in and searched from centralized

repositories such as the UDDI [21] services. REST employes URIs to

identify its resources. The main advantage of using URI is that it contains

all the necessary information for service discovery and invocation on

global addressing space without requiring any centralized repository [18].

URIs are readable, distributable and can be bookmarked or printed [18].

Because of the HATEAOS principle, the application state is driven by the

server in REST. Which means that the client needs to know the URI for

the starting service only. Additional states for the requested resource and

relevant services can be found in the responses received from the server,

which makes service discovery much simpler.

4.3 Empirical studies

Mulligan and Gračanin [16] performed benchmark tests on their proposed

interaction independent middleware framework - the so-called Portal

framework. The Portal framework contains two implementations of data

transmission component: one following REST principles and the other

with SOAP [16]. The performance tests executed on Portal framework

(48)

shows that, for almost every tests conducted, the REST implementation

incurs less overall latency and requires less bandwidth (due to of smaller

packet size) than its SOAP-based counterpart [16].

Al-Zoubi and Wainer [22] claims that REST fulfills Web service objectives

better than SOAP through a comparative performance study between

their RESTfulCD++ [22] and SOAP based DCD++ [23] systems. Both

RESTfulCD++ [22] and DCD++ [23] are distributed simulation software

built with Web service technologies – REST and SOAP, respectively.

Following the REST principles, RESTfulCD++ system was able to see

performance boost in terms of execution time and number of remote

simulation messages exchanged [22].

Aihkisalo and Paaso [24] conducted a case study in which they measured

latencies experienced by Web service clients invoking a proprietary

multimedia messaging service. The messaging service had both REST and

SOAP interfaces implemented. Comparisons were made between

SOAP-XML, REST-XML and REST-JSON implementations. The analysis of the

results obtained through the study revealed that the SOAP based solution

was 4 – 5 times slower than the REST [24]. The authors concluded that

this is not only because of the utilized XML encoding (the REST-XML was

much faster as well), but also because of the intrinsic complexity of SOAP

[24:105].

In addition, they also compared REST-XML with REST-JSON and

concluded that JSON solution would achieve faster network transmission

due to the smaller size of the serialized objects in JSON than XML

[24:105]. However, since their experimental setting was based on high

bandwidth local loop networking, the results were not conclusive on this

aspect.