point
Menu
Magazines
June - 2008 - issue > Technology
A RESTful paradigm for Web Services
Srihari Srinivasan
Friday, May 30, 2008
If you are a proponent of Web services and follow discussions in the community, then certainly you must have come across the term REST. You probably have also seen headlines such as ‘REST vs. SOA’, ‘REST vs. SOAP’, etc. in magazines, blogs, and forums. While much of the talk around Service Oriented Architectures (SOA) has so far revolved around SOAP and the WS-* stack, recently REST based SOA (also called Resource Oriented Architectures - ROA) has started to silently permeate the Web.

What is REST?
The term REST is an acronym for Representational State Transfer. This term was coined by Roy Fielding, one of the principal authors of the Hypertext Transfer Protocol, in his doctoral dissertation. It is described as an architectural style for building distributed hypermedia systems and is manifested in the architecture of the World Wide Web. More commonly the term REST is also used to describe any simple interface that uses XML over HTTP without an additional messaging layer such as SOAP.

The Origins
The World Wide Web was conceived as an abstract space in which people and machines could interact. It would be chiefly populated by interlinked pages of text, images, etc. Information would be exchanged within this shared space with the users located around the world, creating and modifying it on heterogeneous machine systems.

Beginning with universities and research labs, the usage of the early Web soon grew to such an extent that the Internet developer community became concerned with this rapid growth. Along with some poor network characteristics of early HTTP, they feared this growth will quickly outpace the capacity of the Internet infrastructure and lead to a general collapse.

Consequently working groups within the IETF came up with solutions that eventually manifested in standards such as HTTP, URI, and HTML.

Model for Distributed Computing
REST is basically a model for distributed computing; one that is used by the largest distributed application known, the Web.

Roy Fielding states in his dissertation titled ‘Architectural Styles and the Design of Network-based Software Architectures’, “Representational State Transfer (REST) is an architectural style for distributed hypermedia systems, as it has been developed to represent the model how the modern Web should work. REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.”

In the dissertation, Fielding describes REST as a series of constraints imposed upon the interaction between network components. It is best to understand these constraints within the framework of the familiar Web based interactions.

1. Separation of concerns: This implies partitioning your network components that need to interact as client and server. In any Web-based interaction, the client (i.e. the browser) is responsible for rendering and the server is responsible for processing.

2. Stateless communication between client and server: Requests from a client must carry sufficient context with it so that the server can generate a response without using any context generated from previous interactions. HTTP is basically a stateless protocol, which forces the client to send a request with enough context for the server to generate a response.

3. Cacheability of responses: Every response from a server should indicate if it can be cached on the client and, if so, for how long.

4. Uniform Interface: This is the most important aspect of the REST style and its understanding is the key for building Restful components. So let us look at this in greater detail.

Uniform Interface
Consider the example of a service that allows you to manage your organization’s address book. Services that are architected based on the RPC (Remote Procedure Call) style typically end up with interfaces such as:

getEmployee(name)
getPhoneNumber(name)
getAllEmployeesByLocation(city)
getAllEmployeesByDesignation(something)
createEmpoyee(* args)
updateEmpoyee(* args)
deleteEmpoyee(identifier)

In order to exchange information with this service the client explicitly needs to learn about the network address of the service, the kind of operations the endpoint supports, and type the information to perform the operation.

As we build more services under this model the number of such operations (the verbs) increases continuously, thus resulting in a collection of messages that are only understood by a specific server or by a small subset of components in the architecture.

Such proliferation of operations or functions results in an architecture that is unconstrained. Consequently, orchestrating such functions becomes a lot harder.

REST deviates from the idea of sending ad hoc messages. Instead of creating special purpose functions, services are created as new units of information to be manipulated using standard functions. All requests and responses are understood by every component of the architecture and most of them carry copies of their information as part of the function call. For example, the same information exchanged with the contacts service could also be exchanged in this way:

HTTP GET Request to
http://server.com/employee/somename
HTTP GET Request to
http://server.com/employees?city=someplace
HTTP GET Request to
http://server.com/employees?designation=something
HTTP POST Request to http://server.com/employee
HTTP PUT Request to
http://server.com/employee/somename
HTTP DELETE Request to http://server.com/employee/somename

When the service evolves, the former style encourages addition of more functions while the latter does not. Also, since the interactions are fixed, it is easy to associate predefined semantics to those interactions. For example, in order to create an employee a client will always perform a POST operation on an endpoint identified as http://server.com/employee and a PUT operation to update.

New Paradigm for Web Services
In essence, by standardizing the interactions we have applied the principle of generality to component interfaces. This leads to an architecture with a plethora of service end points, but each endpoint providing a predictable and consistent set of interactions (which is what we care about the most). The resulting ease and simplicity is what sets REST-based SOAs apart from their more complex SOAP-based cousins. For the same reason REST-based SOAs are bound to see much wider adoption in enterprises and around the Web than SOAP-based SOAs.

The paradigm that REST promotes is to replace the ‘do something’ concept with a ‘make something so’ concept. If you think about it, all ‘do something’ concepts can be modelled this way too!

The key principles that can be used to drive REST-based SOAs can be summarized as:
1) Identify units of information available on the network – this is called a ‘Resource’.
2) Every resource must be distinctly identifiable on the network through a URI.
3) The information encapsulated by the resource is the ‘State’ of that resource.
4) Each resource must support operations with predefined semantics.
5) Operations are performed on a resource by sending a ’Representation’ of that resource.
6) The format of the representation is the ‘Media type’.
7) Hypermedia as the engine of application state - Interactions with a resource should also reveal further actions or state transitions possible in the form of hyper links.

Conclusion
The simplicity of HTTP and the absence of tools and frameworks in your language of choice may make you dismiss REST. But, even if you believe SOAP-based SOA as more appropriate, understanding REST will be a worthwhile exercise as it can help you build better distributed systems.

The author is Consultant and Senior Developer, ThoughtWorks Inc. He can be reached at srihari.srinivasan@gmail.com
Twitter
Share on LinkedIn
facebook

ON THE DECK