ISSN: XXXX-XXXX Volume X, Issue X, Month Year
Compulsiveness of RESTful Web Services
Ashok Kumar. P.S
Asst. Prof, Dept of ...
International Journal of Innovatory research in Engineering and Technology - IJIRET
ISSN: XXXX-XXXX Volume X, Issue X, Mon...
International Journal of Innovatory research in Engineering and Technology - IJIRET
ISSN: XXXX-XXXX Volume X, Issue X, Mon...
International Journal of Innovatory research in Engineering and Technology - IJIRET
ISSN: XXXX-XXXX Volume X, Issue X, Mon...
Upcoming SlideShare
Loading in …5
×

Ijirsm ashok-kumar-ps-compulsiveness-of-res tful-web-services

295 views
250 views

Published on

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.

Published in: Design, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
295
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ijirsm ashok-kumar-ps-compulsiveness-of-res tful-web-services

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

×