Web Services: SOAP Vs

Web Services: SOAP vs. REST <author name> (Studentnumber:<number>) November 17, 2006 Abstract It is unanimously believed that Web services will move the Web to its next level by facilitating application to application interaction over the Internet. However, there is no consensus on how Web services should be implemented. Software vendors promote involved tool-chains that are based on SOAP, a W3C standard, as the ideal technology, while a few, but vocal practitioners claim that a simpler approach, called REST, is often more appropriate. In this paper, we investigate the fundamental underpinnings of SOAP and REST. Furthermore, we discuss the applicability of SOAP and REST in different domains. 1 Introduction To realize the full potential of the nowadays ubiquitous infrastructure of the Web, it is necessary to extend the scope of the Web beyond human-oriented browsing to include application to application interactions, which are enabled by programmatic interfaces. These programmatic interfaces are re- ferred to as Web services [44]. How these programmatic interfaces should be realized is a matter for, sometimes heated, debates [17]: the debate of SOAP versus REST. SOAP, a W3C standard, which is backed by all majors vendors (including BEA Systems, IBM, Microsoft, and SUN), allows the exchange of information between peers in a decentralized, distributed environment. Moreover, a huge and growing number of protocols [47] enhance SOAP with advanced features such as reliability, security, and transaction support; or standardize application-oriented pro- cedures for complex interactions among businesses. REST, in contrast, is neither a standard nor is it promoted by any vendor. REST, which stands for Representational State Transfer, has been first described in Roy Fielding’s PhD thesis as an “architectural style for distributed hypermedia systems” [13, p. 4]. Fielding, co-founder of the Apache HTTP Server project and one principal author of the Hypertext Transfer Protocol [14], attributes the ability of the Web to sustain its exponential growth to the principles of the REST architectural style [15]. Hence, it is enticing to apply the same principles to building Web services. 2 Representational State Transfer (REST) 2.1 REST as an Architectural Style Strictly speaking, REST refers to the architectural style that is described by Fielding’s PhD thesis [13]. However, the term is also loosely used to differentiate Web services with sophisticated, SOAP-based programming interfaces from Web services that simply utilize HTTP and XML (or an equivalent 1 technology) to provide their programming interface; in this sense, the term REST is used [46] even if those Web services do not fully adhere to the architectural style defined by Fielding. In the following, we will use the term REST according to the definition given in Fielding’s PhD thesis: REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent de- ployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. [13, p. 75] 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] . Moreover, those principles have become an important part of the general architecture of Web [22]. The principles of the REST architectural style consists of [13, section 5.1]: • a layered, stateless client/server design with caching of requests; • a uniform interface between components; and • optionally: code-on-demand support. To illustrate above principles and some of their implications that are mentioned in [13, chapter 3 and 5], we describe them in the context of Web applications. Layered, stateless client/server design and caching Web applications are partitioned in a client component and a server component where the server component provides services to the client component. The client component, for example, could be a Web browser and the server component a Java Servlet running in a Web server, which communicates with the client over the stateless HTTP protocol. REST principles mandate that the server is stateless. Therefore, the server cannot hold any session state, and client requests necessarily contain all information needed to understand a request in isola- tion; hence, a request can be understood without referring to earlier requests. Furthermore, the server’s stateless design simplifies its implementation and improves server scalability because the server can release resources after each request. REST allows to insert additional layers between client and server in form of intermediary components, which relay messages and may provide additional services. As a constraint, layers are visible only to their immediate neighbours, thus layers behind the immediate neighbours of a component remain hidden to the component. Consequently, layers are decoupled from each other, and the flex- ibility to deploy and evolve components is increased. Reverse-proxy servers are an example of an intermediary component. A reverse-proxy server can be installed in front of a cluster of Web servers toprovideload-balancingortothesecurecommunicationtotheclientbySSLencryption. Furthermore, intermediary components may cache the result of requests if staleness of data is not an issue. Thus by placing a caching component near the client, the latency perceived by the client can be vastly reduced. An example of a caching component is a (caching) Web proxy. Uniform interface Fielding emphasizes that a uniform interface between components is the key principle that differen- tiates REST from other network-based architectures. To attain a uniform interface, REST defines 2 four constraints: “[...] identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.” [13, p. 82]. We discuss these principles in the following: Any kind of information that is offered by a REST interface is represented as a resource. Each resource is addressable by a (global) resource identifier. Furthermore, a resource need not refer to a physical resource, but it can also represent an abstract concept which, for example, refers to different physical resources over time such as the latest version of a document. Components manipulate resources by applying a generic set of operations on the representation of a resource. Representations consist of data (that is, a sequence of bytes) and meta data. If a resource has multiple representations such as a document that is available in multiple formats, the server delivers the representation that best fits the client component. Exchanged messages must be self-descriptive. Self-descriptive means that a message can be pro- cessed without referring to previous messages or to data that is transferred outside of the message (for example, data contained only in the underlying transport protocol). Finally, REST applications use hypermedia to change application state: A client accesses resources by their representation, which may contain links to (representations of) other resources. By following those links, the application state is transferred from one state to the next. In other words, application state is transferred by following links from one representation to another representation: hence, the name Representational State Transfer. In the context of a Web application, aforementioned constraints can be illustrated as follows: Every resource of the Web application is addressable by a Uniform Resource Identifier (URI) [2]. By issuing a URI together with a (generic) HTTP method, for example GET or POST, a client obtains the resource’s representation or manipulates a resource. For instance, a client could send the server an HTTP GET request to retrieve a journal article as an HTML document and an HTTP POST request to add a comment to the article. Furthermore, the HTML document that represents the article could contain a list of links to other articles; by following one of those links, the client moves to another state. Code-on-demand Code-on-demand support allows adding functionality to clients as needed; hence, the amount of functionality that must be “hard-wired” in each client can be reduced. This style can be implemented, for example by the inclusion of ECMAScript or Java applets in a Web page. It is, however, an optional constraint of REST because code-on-demand support is not always feasible. For instance, download- ing Java applets may be prevented for security reasons at organizational boundaries by firewalls. 2.2 REST Web Services REST does not prescribe how Web services should be implemented: In Fielding’s PhD thesis [13], REST is merely considered as an architectural style that optimizes the characteristics of Internet-scale, distributed hypermedia systems. Yet, numerous articles on the Web [18, 20, 28, 31] provide guidelines for building Web services with REST. To illustrate the REST approach to Web services, we present a conversation between a service consumer and a simple on-line flight booking system that provides a REST-compliant Web service. 3 Example of a REST Web service In this 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

Load more