We believed thatWeb services facilitate application to appli-cation interaction over the Internet. However, clients have no state-of-art on how Web services should be implemented. Service vendors promote services concerned about the value added services that are based on SOAP, it is a W3C standard and ideal technology, while a few, but local developers claim that a simpler approach, called REST, is often more acceptable. In this paper, we investigate the fundamental support of SOAP as well as REST. Furthermore, we cover the relevance of SOAP and REST in different domains.

1. ISSN: XXXX-XXXX Volume X, Issue X, Month Year
Compulsiveness of RESTful Web Services
Ashok Kumar. P.S
Asst. Prof, Dept of Computer Science and Engineering
YD Institute of Technology
Bangalore, India
ashnelgar@gmail.com
Abstract
We believed thatWeb services facilitate application to appli-
cation interaction over the Internet. However, clients have
no state-of-art on how Web services should be implemented.
Service vendors promote services concerned about the value
added services that are based on SOAP, it is a W3C standard
and ideal technology, while a few, but local developers
claim that a simpler approach, called REST, is often more
acceptable. In this paper, we investigate the fundamental
support of SOAP as well as REST. Furthermore, we cover
the relevance of SOAP and REST in different domains.
1. INTRODUCTION
To realize the potential of the ubiquitous infra-
structure of the Web, it is necessary to extend the
scope of the Web include application to applica-
tion interactions, which are enabled by application
programm interfaces. These programm interfaces
are referred as Web services [44]. How these pro-
grammatic interfaces should be realized with
SOAP versus REST.
SOAP, is a W3C standard, which is backed by
all majors vendors like, BEA Systems, IBM, Mi-
crosoft, and Oracle, etc allows to exchange the
information between peers in a decentralized, dis-
tributed environment. Moreover growing number
of protocols enhance the SOAP with advanced
features like reliability, security, and transaction
support for complex interactions among business-
es.
Fig 1 Architecture of web services
REST, means Representational State Transfer,
has been first described in Roy Fielding’s PhD
thesis as an “architectural style for distributed hy-
permedia systems” [13, p. 4]. In scope of REST, is
neither a standard nor is it supported by any ven-
dor.
2. REPRESENTATIONAL STATE
TRANSFER (REST)
2.1 REST as an Architectural Style
REST refers to the architectural style that is de-
scribed by Fielding’s PhD thesis [13]. How ever
SOAP-based programming interfaces from Web
services that simply utilize HTTP and XML to
provide their programming interface. REST pro-
vides a set of architectural constraints [13, p. 75].

2. International Journal of Innovatory research in Engineering and Technology - IJIRET
ISSN: XXXX-XXXX Volume X, Issue X, Month Year 26
The architectural principles defined by REST have
been used by Fielding [15] to guide the design and
evolution of the Hypertext Transfer Protocol
(HTTP) [14] and Uniform Resource Identifiers
(URI) [2]. The principles of the REST architectur-
al style consists of [13, section 5.1]:
1. Layered, stateless client/server design.
2. Uniform interface between compo-
nents.
3. Code-on-demand support.
REST principles mandate that the server is state-
less. Therefore, the server cannot hold any session
state, and client requests necessarily contain all
information needed to understand a request in iso-
lation; hence, a request can be understood without
referring to earlier requests. Furthermore, the
server’s stateless design simplifies its implementa-
tion and improves server scalability because the
server can release resources after each request.
Uniform interface Fielding emphasizes that a
uniform interface between components is the key
principle that differentiates REST from other net-
work-based architectures. To attain a uniform in-
terface,
REST defines four constraints:
1. identification of resources;
2. manipulation of resources through repre-
sentations;
3. self-descriptive messages;
4. Hypermedia as the engine of application
state.
In the context of a Web application, constraints
can be illustrated as follows:
Every resource of the Web application is address-
able by a Uniform Resource Identifier (URI) [2].
http://www.EDSOA/item=&AppleURI
End point Reference
Item price
web services
Fig 2 – End pont Reference
By informing a URI with HTTP method, for ex-
ample GET/POST method, a client obtains the re-
source’s representation or manipulates a resource.
For example, a client could send the request to
server is an HTTP GET request and to retrieve a
article as an HTML document from server is an
HTTP POST request.
2.2 RESTWeb Services
REST is merely considered as an architectural
style that optimizes the characteristics of Internet-
scale, distributed hypermedia systems.
For example, the service consumer of a flight
booking system searches for a flight, books a
flight, modifies the previously made booking, and
finally cancels the booking.
To search for flights, the service consumer sends
an HTTP GET request where the search criteria
are supplied as a query string. The actual HTTP
request is shown below:
GET /flights?departure=America&arrival=
Bengaluru &date=2014-04-19 HTTP/1.1
Host: www.flywho.in
The server replies to the HTTP request with a list
of matching flights. The response could be in any
format, which may by XML or JSON document.
However, XML is usually preferred, because this
format is readable by human as well as machine
easily.
HTTP/1.1 200 OK
<?xml version="1.0"?>
<flight_list
xmlns:xlink="http://www.w3.org/1999/xlink">
<flight no="53" time="12:30"
xlink:href="http://www.flywho.in/flights/53"/>
<flight no="72" time="19:30"
xlink:href="http://www. flywho.in/flights/72"/>
</flight_list>
We assume that the service consumer can create a
new booking. To create a new booking the service
consumer sends a POST request to www. fly-
who.in /bookings, it holds the information about
the flight number and the name of the customer in
the request body:
POST /bookings HTTP/1.1

3. International Journal of Innovatory research in Engineering and Technology - IJIRET
ISSN: XXXX-XXXX Volume X, Issue X, Month Year 27
Host: www.flywho.in
<?xml version="1.0"?>
<booking>
<flightno>53</flightno>
<customer>Ashok</customer>
</booking>
The server adds the booking to the system’s data-
base and returns the URI of the created resource.
Assuming that the URI of the created booking is
www.flywho.in/booking/53, the service consumer
sends the following PUT request to the server in
order to correct the spelling of the customer name.
PUT /bookings/53 HTTP/1.1
Host: www.flywho.in
<?xml version="1.0"?>
<updated_elements>
<new_content select="/booking/customer[0]">
<customer>Ashok PS</customer>
</new_content>
</updated_elements>
3 KEY BEHAVIOR OF RESTful WEB
SERVICES
REST Web services are built-in resource-
oriented, i.e. each and every entity instance is re-
trieved, manipulated or represented by a resource.
Moreover, resources are visible to all service con-
sumers. Resources are identified by Uniform Re-
source Identifiers (URI), which allow service con-
sumers to address each resource.
A URI involves the state of a service consume,
i.e. service providers do not maintain state of ser-
vice consumers. Service consumers manipulate
resources by a set of generic operations consisting
of the four HTTP methods:
1. POST,
2. GET,
3. PUT,
4. DELETE.
These operations are often equal to Create, Read,
Update, and Delete (CRUD) functions database
systems to manipulate records. i.e. GET means
“read” and DELETE means “delete” , POST
means “create” and PUT means “update” .
3.1 Limitations of the REST Approach to
Web Services
The drawback of REST is that, it is not even
standard for building Web services. Furthermore,
REST completely relies on existing Web stand-
ards. Further more, the restriction is that, the ser-
vice interfaces must expressed in terms of re-
sources and have limited set of operations like,
POST, GET, PUT, and DELETE. The resource-
oriented design of REST interfaces involves that
REST Web services, it expose a huge number of
resources by URIs, it is difficult to manage and
expect those URIs.
4 APPLICABILITY OF RESTFUL WEB
SERVICE
REST is designed for Internet and hypermedia
systems. Hence, REST is designed to provide
rich object-oriented interfaces, i.e. REST web
servivces is reffered for Web applications. E-
commerce applications or mere web applications
expect scalability in order to get an entry into a
large user-base. REST Web services can draw
from a large share of vendors because, REST is
easy to develop and design with any development
tool alike. Hence, REST web services satisfy the
demands of e-commerce applications very well.
REST provides no standards to handle long-
running multi-step transactions between entities in
thae trading, i.e. RESTful web service establishes
a standard, because it provides point-to-point
communication over HTTP.
5. CONCLUSION
This paper defines the fundamentals of REST. We
explained the term REST in terms of an architec-
tural style, and the simple approach to build Web
services using HTTP and XML technologies. Fur-
thermore, we explained the key strengths of REST
web services and how simple to make e-commerce
applications for trading applications. For Business

4. International Journal of Innovatory research in Engineering and Technology - IJIRET
ISSN: XXXX-XXXX Volume X, Issue X, Month Year 28
to business scenarios, how RESTful web services
is suitable.
References
[1] Tim Anderson. Ws-* vs the rest, 2006.
[2] T. Berners-Lee, R. Fielding, and L. Masinter. Uni-
form resource identifiers (URI): Generic syntax.
Technical report, 1998. URL
http://www.ietf.org/rfc/rfc2396.txt. RFC 2396.
[3] Tim Berners-Lee. Web architecture from 50,000
feet, 1998. URL http://www.w3.org/DesignIssues/
Architecture.html.
[4] Don Box. A brief history of SOAP, 2001. URL
http://webservices.xml.com/pub/a/ws/
2001/04/04/soap.html.
[5] Don Box, David Ehnebuske, Gopal Kakivaya, An-
drew Layman, Noah Mendelsohn, Henrik Frystyk
Nielsen, Satish Thatte, and Dave Winer. Simple ob-
ject access protocol (SOAP) 1.1. Technical report,
W3C, 2000. URL
http://www.w3.org/TR/2000/NOTE-SOAP-
20000508. W3C Note 08 May 2000.
[6] Jan Christian Bryne, , and Anders Lanzen Computa-
tional Biology Unit. Web services tutorial, 2006.
URL
www.csc.fi/molbio/opetus/embrace/presentations/W
S/Compendium.pdf.
[7] Luis Felipe Cabrera, Christopher Kurt, and Don Box.
An introduction to the web services architecture and
its specifications, 2004. URL
http://msdn2.microsoft.com/en-
us/library/ms996441(d= printer).aspx.
[8] Timothy M. Chester. Cross-platform integration with
XML and SOAP. IT Professional, 3(5):26–34, 2001.
ISSN 1520-9202.
[9] Erik Christensen, Francisco Curbera, Greg Meredith,
and Sanjiva Weerawarana. Web services description
language (WSDL) 1.1. Technical report, 2001. URL
http://www.w3.org/TR/2000/NOTE-SOAP-
20000508. W3C Note 15 March 2001.
[10] Tyler Close. web-calculus, 2005. URL
http://www.waterken.com/dev/Web/Calculus/
[11] Francisco Curbera, Matthew Duftler, Rania Khalaf,
William Nagy, Nirmal Mukhi, and Sanjiva We-
erawarana. Unraveling the web services web: An in-
troduction to SOAP, WSDL, and UDDI. IEEE Inter-
net Computing, 6(2):86–93, 2002.
[12] N. J. Davies, D. Fensel, and M. Richardson. The fu-
ture of web services. BT Technology Journal, 22(1):
118–130, 2004. ISSN 1358-3948.11
[13] R. Fielding. Architectural Styles and the Design of
Network-based Software Architectures. PhD
thesis, University of Califormia, Irvine, USA, 2000.
[14] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T.
Berners-Lee. Hypertext transfer protocol –
HTTP/1.1. RFC 2068, Internet Engineering Task
Force, January 1997. URL
http://www.ietf.org/rfc/rfc2616. txt.
[15] Roy T. Fielding and Richard N. Taylor. Principled
design of the modern web architecture. In ICSE ’00:
Proceedings of the 22nd international conference on
Software engineering, pages 407–416, New York,P.
Decision Support Systems, 40(1):9–29, 2005.