RESTful Web Services - Literature review Example

?RESTful web services as an alternative to “Big Web Services” Introduction Representational Transfer (REST) has become very popular across the Web as this software architecture is considered as a simpler and effective alternative to SOAP and WSDL (Web Services Description Language) based web services. Currently, leading Web 2.0 providers including Google, Yahoo, and Facebook have adopted REST and this trend clearly indicates a shift in interface design. These providers have deprecated the software architectures like SOAP and WSDL based web services as they believe that REST is easy to use and exposes their services in an effective manner. This paper will critically analyse the RESTful web services and the way these web services differ from Big Web Service techniques. RESTful web services The term ‘representational state transfer’ was coined by Roy Fielding in 2000 in his doctoral research paper. REST can be simply defined as software architecture designed for systems like World Wide Web. “REST is a particular style of enabling communication based on the principle that all data as well as operations on data are enabled using strictly static URLs based on the HTTP protocol” (Kashyap et al, 2008, p.207). This architectural model has been developed over the recent years as a widely accepted web service design model. REST has a specific set of architectural principles that assists a user to design customized web services focusing on the resources of a system. As Rodriquez (2008) points out, this model’s simplicity has assisted it to displace interface designs based on WSDL and SOAP over the last few years. Even though this software architecture did not gain much attention during its initial stages, today it is being quickly developed to support web based services. The REST architectural design specifically defines six constraints that have been applied to this software architecture. “Conforming to the REST constraints is generally referred to as being RESTful” (Pixia, 2012). The six constraints applied to the REST architecture are described below. Client-server Clients are separated from servers by a uniform interface. Under this separation of concerns, clients do not deal with data storage and this feature adds to the portability of client code. Similarly, servers do not focus on user interface so that they can be more scalable and simpler. Stateless The communication between the client and the server is further constrained since client contexts are not saved on the server between service requests. All the essential information required to serve the request will be included in requests by any client. Since the servers can be stateful, they will be more visible for monitoring and more reliable in partial network issues. Cacheable Since clients can store responses, they (responses) must be clearly defined as cacheable or not so to prevent clients from reusing improper data in an attempt to service further requests. Effectively managed caching would eliminate some sorts of interactions between client and the server and contribute to scalability and performance (Bhuvaneswari and Sujatha 2011). Layered system Generally, it is not possible for a client to indicate whether or not it is connected to the end server or an intermediary. Since intermediary servers are able to provide shared caches, and enable load balancing, they can significantly improve system scalability. In addition, such intermediary servers can enforce security policies. Code on demand A client’s functionality can be temporarily extended or customized by servers through transfer of executable code. It is the only optional component of REST software architecture. Compiled components like Java applets and client side scripts like JavaScript are some well known examples (Oracle, n.d). Uniform interface The uniform interface between clients and servers play a notable role in simplifying the architecture. The four guiding principles of uniform interface are “identification of resources, manipulation of resources through these representations, self descriptive messages, and hypermedia as the engine of application state” (Sempf et al, 2010). Under the REST model, prime importance is given to data and functionality, and they are accessed with the help of links on the web, called Uniform Resource Identifiers (URIs). Many scholars refer RESTful web services to stateless client-server architecture and consider these web services as resources that can be accessed using URIs. Gorav (2012) states that one of the notable features of RESTful web services is that a resource is directly accessed by client using its URIs. In addition, a client can manipulate resources on the server by means of a fixed set of four options including PUT, GET, POST, and DELETE. The PUT option is used to create a new resource, which can be later deleted using the DELETE option. The GET option is assistable to retrieve the present state of a resource whereas the POST option is applied to convert a new state into a resource (ibid). Another feature of RESTful web services is that it is possible to access the content of resources in a variety of formats like HTML, PDF, JPEG, XML, JSON, and plain text; and metadata concerning the resource is used for several purposes such as caching control, detection of transmission errors, negotiation for the proper representation format, and performance of access control (ibid). However, it must be noted that REST may not be always the appropriate choice. As Rodriquez (2008) points out, often it is only a way to develop web services with less focus on proprietary middleware. Big web services SOAP based web services are often referred to as Big web services. Jendrock et al (2011, p. 204) say that the Big web services work using Extensible Markup Language (XML) messages, which are linked to the SOAP standard. The Big web services are popular in traditional enterprises. Under the system of Big web services, the service specified in the WSDL often offer a machine readable details of the operations (ibid). In Big web services, a formal contract is offered to describe the interface. Generally, WSDL is employed to describe contract details that may include messages, bindings, operations, and the web service location; and many of the Big web services’ customized specifications address complex non-functional requirements and develop a common vocabulary for them (ibid). The Big web services can be viewed as a software architecture that manages and asynchronous processing and invocation. In Big web services, the term ‘big’ refers to various service interaction protocols that are mature, standardized, and highly established in many sectors of the IT industry. Sometimes, the Big web services are referred to as ‘high ceremony’ services mainly due to tighter coupling between service provider and the consumer and focus on strict protocols. Therefore, it is to be noted that Big web services are not so simple. A variety of protocols and standards has been developed for building these web services. According to Richardson and Ruby (2007), such standards are together called WS stack, which include WS-Notification, WS-Security, WSDL, and SOAP. Generally, the WS stack is built on the top of HTTP and is often used for a job where plain old HTTP can perform well. One of the noticeable advantages of Big web services is that it is possible to develop web services from a given code very easily using modern tools. AS Richardson and Ruby (2007) argue, although all web functions are based on resources, Big web services do not expose resources. More precisely, the web operations are centered on URIs and links whereas a Big web service generally use one URI and few links; and similarly, when the web is too much dependent on HTTP, Big web services barely employ HTTP features (ibid). Since these web services are not cacheable or addressable, they do not give importance to any uniform interface. Different Big web services do not generate same WSDL files and analyze standards in the same manner. In addition, different Big web service may not be often capable of understanding each other’s messages. The security of the Big web services are tighter than WS-Security standard. To illustrate, signature can contribute to nonrepudiation. It is possible to identify a given message’s originator even after a long time it was sent. In addition, there are techniques to prove that the given message was not altered after it was delivered. These concepts are of significant importance in contracts. Likewise, the Big web services’ federation feature would assist a travel broker to identify whether or not a given person work for the customers of one of the travel brokers. This feature can have a particular influence on billing and discounts. Finally, various existing features of HTTP are re-implemented by Big web services in opaque ways. Difference between RESTful web services and big web services The most significant difference between RESTful and Big web services is that the former is simpler than that latter. Hence, the RESTful web services provide users with more convenience. While comparing RESTful web services and Big web services, it seems that the former is not widely standardized like the latter. In addition, the Big Web services have a relatively tighter coupling than RESTful web services. Hence, the RESTful web services are called ‘low ceremony’ services whereas the Big web services are referred to as ‘high ceremony’ services. As compared to RESTful web services; Big web services obtain little benefits of resource based web services. RESTful web services are data-centric while Big web services are functionality-centric (Fensel et al. 2011, pp. 69-70). The authors add that there are notable differences between these two concepts even though the RESTful services and Big services have some common principles and technologies (ibid). The authors continue that RESTful services are mainly designed for machine consumption; more precisely, these services are used by other services or applications. In contrast to this, Big web services are designed for human consumption (ibid). Another key difference between these two is that RESTful web services are based on web resources and web principles. Similarly, Big web services are based on SOAP which permits only XML while the REST allows a variety of data formats. Although this feature adds to the complexity of this software architecture, REST can support a wide range of applications. Experts opine that the REST has more improved scalability and performance than Big web services. While it is possible to cache REST reads, SOAP reads cannot be cached. SOAP based web services have developed an effective mechanism that allows services to explain themselves to clients. In case of RESTful services, they can be executed with the help of almost any tool so that they can have lower bandwidth and a relatively short learning curve. As we discussed earlier, REST is build over HTTP whereas the SOAP can be over a variety of transport protocols including FTP, HTTP, STMP, and JMS. In a number of ways, SOAP based web services do not comply with the architecture of the web. Even though bindings are in existence of using SOAP over HTTP, several aspects of SOAP do not follow the architecture of the web. In contrast, REST is based on the architecture of the web. It is one of the major points of difference between RESTful and SOAP based web services. SOAP pays particular attention to actions rather than URIs. In numerous ways, “SOAP is an interoperable cross-platform remote procedure call (RPC) system” ( Flanders 2008, p.4). Evidently, SOAP based web services are more protocol independent while RESTful web services comprise of web and HTTP. Even though some or all of the REST principles can be used over other protocols, RESTful web services would provide improved benefits when REST principles are used over HTTP. In the words of Godbole (2003), a major point of difference between REST and SOAP is that the former gives specific focus on integration of distributed applications whereas the latter pays particular attention to performance (p.592). It is often identified that SOAP based web services have a number of different actions and only one URI. When the SOAP is used over HTTP, it (SOAP) restricts itself to a single part (POST) of the web’s uniform interface. This feature appears to be one of the major limitations of Big web services because even read only results cannot be cached safely as a result of this SOAP restriction. Under RESTful web services, such issues do not cause much trouble. In case of numerous SOAP based services, GET must be used as the verb in majority of the actions since those actions are able to return read only data. SOAP does not use GET and therefore it is not possible to cache SOAP results, because web’s infrastructure “only supports caching responses to GET requests” (Flanders (2008, p.4). A SOAP based service is not really a web service because a SOAP system deliberately neglects much of the architecture of the web (ibid). It is clear that SOAP is intended for using over numerous different protocols but not only HTTP; hence, SOAP is not in a position to take advantages of many of the web’s features that are particularly linked to HTTP. In contrast, such issues would not limit the scope of RESTful web services since REST focuses only on HTTP protocol, and they can take all possible advantages of web’s features. According to Flanders (2008), rather than an architectural style, SOAP can be considered as specification that spells out particular technical details regarding interaction between two endpoints in terms of message representation. In addition, SOAP does not provide any constraint or architectural guidance. On the other hand, RESTful services clearly follow the defined constraints of the REST software architecture. “While SOAP services are based on a service-specific set of actions and a single URI, RESTful services model the interaction with user agents based on resources” (Flanders 2008, p.5). A unique URI represents each resource and the HTTP uniform interface is used by the user agent in order to interact with a resource by means of that URI (ibid). The author continues that RESTful service give more emphasis on nouns like resources than verbs like HTTP methods because a service design is more about URIs than a customer interface (ibid). While the Big web services focus on objects and methods centered interfaces, RESTful web services are dependent of the concept of resources. Conclusion From the above discussion, it is clear that RESTful web services are being developed to be a potential alternative to Big web services. RESTful web services are built based on RESTful architectural style while Big web services are built using SOAP based applications. RESTful web services are centered on six constraints. In many areas, RESTful services can be a potential alternative to Big services as REST has a number of competitive advantages over SOAP. Mainly, the simplicity feature of RESTful web services has persuaded popular Web 2.0 providers including Google, Yahoo, and Facebook to displace SOAP based services. RESTful web services are often termed as low ceremony services while Big web services are alternatively called high ceremony cervices because of these services’ variance in coupling. Finally, Big web services take function on XML whereas RESTful services allow various data formats. However, it must be noted that RESTful web services cannot be an effective substitute to Big web services under all circumstances. References Bhuvaneshwari, N. S and Sujatha, S., 2011. Integrating Soa and Web Services. Denmark: River Publishers. Fensel, D, Facca, F. M, Simperl, E and Toma, I., 2011. Semantic Web Services. New York: Springer. Flanders, J., 2008. RESTful .NET: Build and Consume RESTful Web Services with .NET 3.5. USA: O'Reilly Media, Inc. Godbole., 2003. Web Technologies. New Delhi: Tata McGraw-Hill Education. Gorav, A., 2012. What are RESTful web Services, Gontu Series, [Online] Available at: [Accessed 31 July 2012]. Jendrock, E, Evans, I, Gollapudi, D, Haase, K and Srivathsa, C., 2011. The Java EE 6 Tutorial: Basic Concepts. India: Pearson Education. Kashyap, V, Bussler, C and Moran, M., 2008. The Semantic Web: Semantics for Data and Services on the Web. USA: Springer. Oracle., n.d, Integrating RESTful web services, J Developer Tutorials, [Online] Available at: [Accessed 31 July 2012]. Pixia., 2012. A revolutionary approach to big data, [Online] Available at: [Accessed 31 July 2012]. Richardson, L and Ruby, S., 2007. RESTful web services, O’Reilly, pp. 1-409. [Online] Available at: < http://tinoweb.googlecode.com/files/O'Reilly%20-RESTful.Web.Services.pdf > [Accessed 31 July 2012]. Rodriquez, A., 2008. RESTful Web services: The basics, IBM, [Online] Available at: [Accessed 31 July 2012]. Sempf, B, Sphar, C and Davis, S. R., 2010. C# 2010 All-in-One for Dummies. Canada: Wiley Publishing. Read More