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].

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 priceweb 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

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

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.