RESTfull Web Services

When we talk about web services there are two solutions raised up: SOAP Web
Services and Restful Web Services. Each of them have its own characteristic and
features to accomplish there jobs. Actually there some similarities and
differences between them we will discuss it in the paper.
Researchers and developers are now considering RESTful Web services as an
alternative that might be more adequate than SOAP-based Web services in some
cases. RESTful Web services are deemed more lightweights because they dont
use SOAP or any other application layer protocol except for HTTP. (Christensen,
2009)

Introduction
REST is an acronym for REpresentative State Transfer. It was first introduced in
the doctoral dissertation of Roy Thomas Fielding in 2000. (Fielding, 2000) REST
is a style, not a standard. There is neither a REST RFC, nor a REST protocol
specification nor something similar.
REST is a hybrid style derived from several of the network-based architectural
styles and combined with additional constraints that define a uniform connector
interface. Roy Fielding described REST as an architecture style, which attempts
to minimize latency and network communication, while at the same time
maximizing the independence and scalability of component implementations
The design rationale behind the Web architecture can be described by an
architectural style consisting of the set of constraints applied to elements within
the architecture. By examining the impact of each constraint as it is added to the
evolving style, we can identify the properties induced by the Webs constraints.
Additional constraints can then be applied to form a new architectural style that
better reflects the desired properties of a modern Web architecture. This section
provides a general overview of REST by walking through the process of deriving
it as an architectural style. Later sections will describe in more detail the specific
constraints that compose the REST style. (Tilkov, 2008)
1

Even though REST is heavily influenced by the WebTechnology, in theory the

REST architecture style is not bound to HTTP. However, HTTP is the only
relevant instance of the REST. For this reason this article describes REST
implemented by using HTTP. Often this is called RESTful HTTP.
The idea behind RESTful HTTP is to use the existing features and capabilities of
the WEB. REST does not invent new technologies, components or services.
RESTful HTTP defines the principles and constrains to use the existing WEB
Standards in a better way.

REST Characteristics
The key aspects of REST that make it desirable for mobile applications are these:

REST is stateless,
o Minimizing the impact of network volatility

REST is URL based,

o Therefore easy to invoke

REST responses are usually HTTP based,

o Therefore discrete
o Also minimizes the impact of network volatility.

REST delivery can be made very succinct

o Lends itself to constrained memory environments.
o No superfluous protocol elements

REST as the connectivity layer

REST makes a nice connectivity layer between cloud environments and mobile
platforms, especially when used in conjunction with HTTP. The ease of
generating the request is a convenience in environments where formulating
complex XML tree structures is both cumbersome and expensive in terms of
memory and processing.
The response is discrete, minimal in its form, and since it, at times, only includes
minimal HTTP headers and is therefore memory friendly. We can determine the

outcome by using standard HTTP error codes, and the body is either empty, or
contains the minimal set of data required to satisfy the request.
The body can be encoded binary information, text, XML, or HTML depending on
the prearranged agreement between the client and server. This direct resource
based response significantly reduces the time, processor, and memory resources
required to process a REST response in order to transform it to a state in which
it is usable by the application.

RESTfull Strengths

RESTful Web services are perceived to be simple because REST leverages

existing well-known W3C/IETF standards (HTTP, XML, URI, MIME) and
the necessary infrastructure has already become pervasive.

HTTP clients and servers are available for all major programming
languages and operating system/hardware platforms

The default HTTP port 80 is commonly left open by default in most

firewall configurations.

The effort required to build a client to a RESTful service is very small as

developers can begin testing such services from an ordinary Web
browser, without having to develop custom client-side software.

Deploying a RESTful Web service is very similar to building a dynamic

Web site.

Furthermore, thanks to URIs and hyperlinks, REST has shown that it is

possible to discover Web resources without an approach based on
compulsory registration to a (centralized) repository.

On the operational side, it is known how to scale a stateless RESTful Web

service to serve a very large number of clients, thanks to the support for
caching, clustering and load balancing built into REST.

REST optimize the performance of a Web service, due to the possibility of

choosing lightweight message formats, e.g., JSON or, even plain text for
very simple data types. (Pautass, 2008)

Weaknesses

Lake of standards, thus, only 2 verbs (GET for idempotent requests, and
POST for everything else) are used. This is due to the fact that proxies and
firewalls may not always allow HTTP connections that use any other verb.
Also, POST and GET are the only two verbs that can be used in the method
attribute of an XHTML form5. These restrictions have led to a series of
workarounds, where the real verb is sent using either a special HTTP
header (X-HTTP-Method-Override) or like with Ruby on Rails a hidden
form field (method).

For idempotent requests having large amounts of input data (more than
4 KB in most current implementations) it is not possible to encode such
data in the resource URI, as the server will reject (HTTP Code 414 Request-URI too long ). Inherently, the POST method does not suffer from
such limitations.

Absent of some Enterprise level features:

o

ACID properties!

Enterprise security features!

Performance
According to Belqasmi (2012) study it show that processing SOAP-based Web
service requests in a mobile environment can take 10 times longer and consume
eight times more memory than an equivalent RESTful Web service request.
The differences between the execution delays in a distributed environment and
in a single machine approximate the network delays for transferring messages
through the network. These differences are two to four times higher for SOAP
requests. This can be explained by the SOAP overhead in terms of network load.
This overhead is due to the mandatory SOAP body (which, for instance, must be
sent to get conference information, while the counterpart RESTful requests body
is empty) and the extra information added in SOAP messages (such as the SOAP
envelope). The network load over- head is two to three times less when using a
REST interface.

References
Belqasmi, F., Singh, J., YOUNIS BANI MELHEM, S., & Glitho, R. H. (2012). Soapbased vs. restful web services: A case study for multimedia conferencing.
IEEE internet computing, 16(4), 54-63.
Christensen, J. H. (2009, October). Using RESTful web-services and cloud
computing to create next generation mobile applications. In Proceedings of
the 24th ACM SIGPLAN conference companion on Object oriented
programming systems languages and applications (pp. 627-634). ACM.
Fielding, R. T. (2000). Architectural styles and the design of network-based
software architectures (Doctoral dissertation, University of California,
Irvine).
Pautasso, C., Zimmermann, O., & Leymann, F. (2008, April). Restful web services
vs. big'web services: making the right architectural decision. In
Proceedings of the 17th international conference on World Wide Web (pp.
805-814). ACM.
Tilkov, S. (2008). A brief introduction to REST, 2007. URL http://www. infoq.
com/articles/rest-introduction.[Online.