RESTful Web Services for the Internet of Things

armyfertileSecurity

Nov 3, 2013 (4 years and 7 days ago)

149 views

RESTful
Web Services for t
he Internet of Things
Markku Laine

Department of Media Technology

Aalto University School of Science

P.O. Box 15400, FI
-
00076 Aalto, FINLAND

markku.laine@aalto.fi




Abstract

In the coming years, the size and scope of the Interne
t
will greatly increase as physical world devices (e.g., sensors and
home appliances) are becoming smart enough to communicate
and share data over the Internet

a phenomenon known as the
Internet of Things (IoT). The problem
of realizing the IoT
is,
however, how to effectively
penetrate the devices into the existing
Web. In this paper, we present Constrained Application Protocol
(CoAP) and other key enabling technologies together with an
end
-
to
-
end IP and RESTful Web Services based architecture for
integrating physical world dev
ices in constrained environments
with the Web.

Keywords
-
CoAP;

HTTP; Internet of Things; REST; Web
Services

I.

I
NTRODUCTION

In the vision of
the Internet of Things (IoT)
, the Internet is
spreading beyond its core (e.g., routers and servers) and
quickly growing
fringe (e.g., personal computers and smart
phones) to trillions of small embedded devices (e.g., sensors) in
the physical world [17]. This huge growth brings both exciting
possibilities and challenges to the Internet, such as how to
seamlessly integrate c
onstrained devices with the Web.

One way to naturally unify the cyber
-
world and the
physical world is to reuse existing web technologies and
standards as much as possible, a research trend treating the IoT
as
the Web of Things (WoT)
[21]. In the WoT, devic
es not only
become IP enabled and interconnected on the Internet but also
become enabled to speak the same language, and thus will be
able to communicate and interoperate freely on the Web. In
order to realize this vision, re
-
designing and optimizations in

payload encoding and application protocols needs to be
conducted to meet the special requirements of machine
-
to
-
machine (M2M) applications over constrained environments on
the IoT.

The rest of the paper is organized as follows. Section II
discusses the ad
vantages of using RESTful Web Services over
arbitrary Web Services in the context of the IoT. Sections III
and IV describe CoAP and how it overcomes the limitations of
HTTP in constrained environments. In Section V, we present
an end
-
to
-
end IP and RESTful
Web Services based architecture
for extending the Internet to constrained environments. Section
VI concludes.

II.

REST
FUL
W
EB
S
ERVICES

Web Services [1] provide a standard and interoperable
means for M2M communication on the Internet. The two major
classes of W
eb Services are: (1) Representational State
Transfer (REST) [7] compliant Web Services, in which
resources are manipulated using a uniform set of “stateless”
operations and (2) arbitrary Web Services (WS
-
*), which
expose an arbitrary set of operations and
use, for example,
SOAP messages [8] [9].

In the context of the
IoT
, the RESTful Web Services have
many advantages over arbitrary Web Services (i.e., SOAP),
such as less overhead, less parsing complexity, statelessness,
and tighter inte
gration with HTTP [17]. In addition,
applications supporting RESTful Web Services perform better
on wireless sensor nodes with limited resources [20] as well as
are considered easier to learn and implement [10]. For a formal
description of RESTful Web Serv
ices either Web Services
Description Language (WSDL) 2.0 [2] or Web Application
Description Language (WADL) [11] can be used.

III.

C
ONSTRAINED
A
PPLICATION
P
ROTOCOL

Although HTTP is widely used with Web Services, it is by
no means the only protocol for M2M commu
nication. In June
2010, the Internet Engineering Task Force (IETF) Constrained
RESTful Environments (CoRE) working group published the
first draft of a RESTful web transfer protocol called
Constrained Application Protocol (CoAP) [16
]
. CoAP includes
several
HTTP functionalities which have been re
-
designed for
M2M applications over constrained environments on the IoT,
meaning it takes into account the low processing power and
energy constraints of small embedded devices, such as sensors.
In addition, CoAP off
ers a number of features that HTTP lacks,
such as built
-
in resource discovery, IP multicast support, native
push model, and asynchronous message exchange. There are
many implementations of CoAP in various languages, such as
libcoap
1
(an open
-
source C
-
imple
mentation) and Sensinode’s
NanoService
2
.




1
libcoap,
http://libcoap.so
urceforge.net/

2
NanoService,
http://www.sensinode.com/EN/products/nanoservice.html

IV.

T
HE
C
O
AP

P
ROTOCOL
S
TACK

The International Organization for Standardization (ISO)
has defined the seven
-
layer Open Systems Interconnection
(OSI) reference model [22]. Next, we will go through the
layers from 1 to 4 a
s well as 7 of the OSI model (cf. Fig. 1),
and describe how the CoAP protocol stack overcomes the
challenges of the IoT compared to a typical HTTP protocol
stack.

A.

Physical Layer and Data Link Layer

Wireless networks are essential for the IoT because wirein
g
up sensors is too expensive. The IEEE 802.15.4 standard [12]
specifies the physical layer (PHY) and media access control
(MAC) for low
-
rate wireless personal networks (LR
-
WPANs),
which focuses on low
-
power consumption, low cost, and low
data transfer rat
e communication between constrained devices.

B.

Network Layer

IPv6 over Low
-
Power Wireless Personal Area Networks
(6LoWPAN) standard [13] [14], defined by the IETF, brings
the Internet Protocol (IP) to small embedded devices (e.g.,
sensors) in even the most
constrained networks, such as IEEE
802.15.4. In addition to 6LoWPAN, the IETF Routing over
Low Power and Lossy Networks (ROLL) working group has
defined IPv6 Routing Protocol for Low Power and Lossy
Networks (RPL) [19] for smart object internetworking.
Tog
ether these networking technologies provide means for
small embedded devices to integrate into the Internet.

C.

Transport Layer

HTTP typically relies on the Transmission Control Protocol
(TCP), which has performance problems over Low
-
Power and
Lossy Networks
(LLNs), is sensitive to mobility, does not
provide multicast support, and has high overhead for short
-
lived transactions [17]. CoAP, on the other hand, is built on top
of the User Datagram Protocol (UDP), which provides
significantly lower overhead and sup
ports multicast.

D.

Application Layer

As described earlier, CoAP provides RESTful Web
Services optimized for resource
-
constrained netwo
rks and
devices, and thus makes
the protocol suitable to the IoT and
M2M applications. In addition, it provides reliabilit
y (with
default timeout and exponential back
-
off retransmission)
mechanisms even without the use of TCP as transport layer.
One of the most important design goals of CoAP has also been
to keep the message overhead as small as possible.

HTTP can also be use
d over 6LoWPAN. However, the
results show that the power consumption and bytes transferred
per transaction are drastically lower when using CoAP over
6LoWPAN compared to HTTP over 6LoWPAN, and thus
increasing the battery lifetime of constrained devices [5]
.

E.

Payload

The W3C Efficient XML Interchange (EXI) [15] format is
a very compact, high performance Extensible Markup
Language (XML) representation, which significantly reduces
bandwidth requirements without compromising efficient use of
other reseources, su
ch as battery life, code size, processing
power, and memory.

In [17], four encoding techniques (XML, EXI
3
, BXML, and
Fast Infoset) were compared using typical sensor markup
languages (RDF, ZigBee Smart Energy, and OGC SensorML).
The results show that EXI e
ncoding is superior, having up to
97 percent smaller size than the equivalent XML, making it a
reasonable option to be used over 6LoWPAN and similar
constrained networks. According to [4], the pure compression
efficiency for EXI is extremely good compared
to other
compression schemes (Gzip, enhanced Xmill (Xwrt), and
XMLPPM).

V.

E
XTENDING THE
I
NTERNET TO
C
ONSTRAINED
E
NVIRONMENTS

Fig. 2 illustrates an end
-
to
-
end IP and RESTful Web
Services based architecture for integrating constrained devices
with the Web. The
architecture allows realizing the same
interface design over HTTP and CoAP because both protocols
implement the REST paradigm.




3
Strict schema
-
informed mode with bit alignment


Figure 1.

The Constrained RESTful Envir
onments (CoRE) architecture
[
18
]



Figure
1
. Comparison of (a) HTTP and (b) CoAP protocol stack
s

In order to provide a client of a protocol to transparently
access resources of a server of another protocol, a device
providing
cross
-
p
rotocol HTTP
-
CoAP mapping [16]

HTTP
-
CoAP cross
-
protocol proxy (HC proxy) [3]


is needed. In
their paper [6], Colitti
et al.
describe the design and
implementation of such a system, which integrates a
REST/CoAP wireless sensor network
(WSN)
with a
REST/H
TTP web application to allow a visualization of WSN
measurements in a web browser.

VI.

C
ONCLUSION

In this paper, we discussed on the utilization of RESTful
Web Services in the context of the Internet of Things (IoT). We
introduced a promising, RESTful web tran
sfer protocol called
CoAP, which is similar to HTTP but has been re
-
designed and
optimized especially for machine
-
to
-
machine (M2M)
applications over constrained environments on the IoT.
According to recent studies, it seems that the use of standards
(e.g.,
CoAP and EXI) and web paradigms are the key success
factors for extending the Internet to constrained environments
and making the vision of the IoT become reality.

R
EFERENCES

[1]

D. Booth
et al.
, “Web Services Architecture,”
W3C Working Group
Note
, February 2
004.
http://www.w3.org/TR/ws
-
arch/
.

[2]

D. Booth and C.K. Liu, “Web Services Description Language (WSDL)
Version 2.0 Part 0: Primer,”
W3C Recommendation
, June 2007.
http://www.w3.org/TR/wsdl20
-
primer/
.

[3]

A. Castellani, S. Loreto, A. Rahman, T. Fossati, and E. Di
jk, “Best
Practices for HTTP
-
CoAP Mapping Implementation,”
IETF Internet
-
Draft 02
, October 2011.
http://tools.ietf.org/html/draft
-
castellani
-
core
-
http
-
mapping
-
02
.

[4]

A. Castellani, M. Gheda, N. Bui, M. Rossi, and M. Zorzi, “Web Services
for the Internet of Th
ings through CoAP and EXI,”
Proc.
IEEE
International Conference on Communications Workshops (ICC’11)
, July
2011.

[5]

W. Colitti, K. Steenhaut, and N. De Caro, “Integrating Wireless Sensor
Networks with the Web,”
Proc.
Extending the Internet to Low Powe
r
and Lo
ssy Networks (IP+SN’11
)
, 2011.

[6]

W. Colitti, K. Steenhaut, N. De Caro, B. Buta, and V. Dobrota, “REST
Enabled Wireless Sensor Networks for Seamless Integration with Web
Applications,”
Proc.
the
Eigth IEEE International Conference on
Mobile Adhoc and Sensor S
ystems (MASS
’11
)
, 2011.

[7]

R.T. Fielding, “Architectural Styles and the Design of Network
-
based
Software Architectures,”
Ph.D. Thesis
, University of California, Irwine,
2000.

[8]

M. Gudgin
et al.
, “SOAP Version 1.2 Part 1: Messaging Framework
(Second Edition),”
W
3C Recommendation
, April 2007.
http://www.w3.org/TR/soap12
-
part1/
.

[9]

M. Gudgin
et al.
, “SOAP Version 1.2 Part 2: Adjuncts (Second
Edition),”
W3C Recommendation
, April 2007.
http://www.w3.org/TR/soap12
-
part2/
.

[10]

D. Guinard, I. Ion, and S. Mayer, “In Search of a
n Internet of Things
Service Architecture: REST or WS
-
*? A Developers’ Perspective,”
Proc.
the Eigth International ICST Conference on Mobile and
Ubiquitous Systems (Mobiquitous’11)
, 2011.

[11]

M. Hadley, “Web Application Description Language,”
W3C Member
Submis
sion
, August 2009.
http://www.w3.org/Submission/wadl/
.

[12]

IEEE, “Part 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low
-
Rate Wireless Personal
Area Networks (WPANs),”
IEEE Std 802.15.4d
-
2009
, April 2009.
http://standar
ds.ieee.org/getieee802/download/802.15.4d
-
2009.pdf
.

[13]

N. Kushalnagar, G. Montenegro, and C. Schumacher, “IPv6 over Low
-
Power Wireless Personal Area Networks (6LoWPANs): Overview,
Assumptions, Problem Statement, and Goals,”
IETF RFC 4919
, August
2007.
http://
tools.ietf.org/html/rfc4919
.

[14]

G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, “Transmission of
IPv6 Packets over IEEE 802.15.4 Networks,”
IETF RFC 4944
,
September 2007.
http://tools.ietf.org/html/rfc4944
.

[15]

J. Schneider and T. Kamiya, “Efficient XML Int
erchange (EXI) Format
1.0,”
W3C Recommendation
, March 2011.
http://www.w3.org/TR/exi/
.

[16]

Z. Shelby, K. Hartke, C. Bormann, and B. Frank, “Constrained
Application Protocol (CoAP),”
IETF Internet
-
Draft 08
, November 2011.
http://tools.ietf.org/html/draft
-
ietf
-
c
ore
-
coap
-
08
.

[17]

Z. Shelby, “Embedded Web Services,”
J.
IEEE Wireless
Communications
, vol. 17, no. 6, pp. 52
-
57, December 2010.

[18]

Z. Shelby, “Embedded Web Services,”
lecture slides
, November 2011.
https://noppa.aalto.fi/noppa/kurssi/t
-
110.5150/luennot/T
-
110_5150
_embedded_web_services_in_iot.pdf
.

[19]

T. Winter
et al.
, “RPL: IPv6 Routing Protofol for Low Power and Lossy
Networks,”
IETF Internet
-
Draft 19
, March 2011.
http://tools.ietf.org/html/draft
-
ietf
-
roll
-
rpl
-
19
.

[20]

D. Yazar and A. Dunkels, “Efficient Application Integ
ration in IP
-
Based
Sensor Networks,”
Proc.
the First ACM Workshop on Embedded
Sensing Systems for Energy
-
Efficiency in Buildings (BuildSys’09)
,
November 2009.

[21]

D. Zeng, S. Guo, and Z. Cheng, “The Web of Things: A Survey (Invited
Paper),”
J.
Communications
,
vol. 6, no. 6, pp. 424
-
438, September 2011.

[22]

H. Zimmermann, “OSI Reference Model

The ISO Model of
Architecture for Open Systems Interconnection,”
J.
IEEE Transactions
on Communications
, vol. 28, no. 4, pp. 425
-
432, April 1980.