In the world full of design principles and architectures, every new architectural style promises to learn from the failures and fill gaps left open by previous ones. With so many architectural recommendations and frameworks around, what makes REST special and why it matters? Answer is simple it make “World wide web” or more popularly called “Internet” work and work like dream. Yes, our very own Internet is a loose implementation of REST principles or in other words internet is almost “RESTful”. Some people even go to the extent of calling REST as an extension of HTTP design.
REST stands for Representational State Transfer; this term was coined by Roy Fielding in 2000 in his doctoral dissertation. Roy is one of principal writer of hyper text transfer protocol (HTTP) specifications; dissertation is available online here <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>. REST concepts have been around for quite sometime but recent emergence of service based designs have put it under spotlight. As Roy has summed
“[REST] scales well with large numbers of clients, enables transfer of data in streams of unlimited size and type, supports intermediaries (proxies and gateways) as data transformation and caching components, and concentrates the application state within the user agent components.”
We started with fewer and smaller organizations with even smaller IT solutions. Need for components communicating/transacting with each other were limited but as enterprises and businesses crossed geographical and demographical boundaries large scale integration became need of hour. Conventional architecture allowed less strict rules which resulted in disparate system which are hard to integrate without getting into low level implementation details. Designer around the world felt need for more standardized approach to how components should be modeled to make integration easier.
Service oriented architecture and web services gained momentum on promise of integrating heterogeneous systems with utmost ease. SOAP interfaces (web services) solved many integration issues but complexities of solutions sometime resulted in more problems than intended solutions. Even flexible WSDL interfaces could not achieve complete independence from underlying implementation. It’s almost impossible for two arbitrary designed components to work together without knowing interface conventions and transfer messages. REST tried to address issues related to non restricted architectural styles resulting into to component specific implementations.
As architectural style, REST defines set of rules which system should comply with to achieve “RESTfulness” and reap the benefits. Why it is more appropriately called style because REST is very abstract as it does not define too many low level details unlike conventional architectures thus rather than being a concrete design it represent a style for architecting services. By defining rules at highest level REST tries to prevent low level component locking. In past decade internet amazed everyone with growth, for a business to be successful internet presence become absolute necessity. Internet can be termed as biggest integration project in the history of computers and its architecture supported speedy expansion really well. This helped in making REST case even stronger.
At the core of REST is stateless client server interactions using uniform interface using which representation of resource state is transferred to requester client. It radically shift design from being API centric to information/domain data centric. You must have heard a lot about interface based design as generally termed as “design to interface” where underlying implementations are abstracted from consumer clients. Pretty neat, but REST takes it to next level by keeping interface constant. Every piece of information offer same set of methods with single identification scheme. New services add new piece of information which can retrieved/manipulated using standard requests. Unlike to RPC style systems, where services are modeled around what they do.
In formal terms REST defines objects as Resources, Resources are identified by single identifier scheme typically a URL or URI, implementing similar set of methods to support information manipulation and retrieval, thus each involved component understand each request and response. Each part of request complies with an interface. There are no adhoc messages. Conventional design proposes "do something" Vs REST's "make something so" though both result in similar outcome but focus moves from verb to noun.
GET - Retrieve information or state of resource
PUT - Update information or state of resource
POST - Add information
DETETE - Remove information
These methods are borrowed from HTTP, though REST is not tied with HTTP but as present most successful implementation of REST style, internet is based on HTTP so it has found way in to the REST acronyms. “GET” being most used method in web application to retrieve information is well suited for extending its role to RESTful designs. Basic idea is to implement these standard set of methods for each entity or resource to enable standard retrieval and manipulation across the heterogeneous, geographically separated systems.
Here is an example* to show conventional Vs REST implementation, An RPC application might define operations such as the following:
getUser()
addUser()
removeUser()
updateUser()
getLocation()
addLocation()
removeLocation()
updateLocation()
listUsers()
listLocations()
findLocation()
findUser()
Client code to access this application may look something like this:
exampleAppObject = new ExampleApp('example.com:1234')
exampleAppObject.removeUser('001')
With REST’s resource centric approach
http://example.com/users/{user} (one for each user - where {user} is either the user name or the user id)
http://example.com/findUserForm
http://example.com/locations/{location} (one for each location - where {location} is the location name or the location id)
http://example.com/findLocationForm
Client code to access this application may look something like this:
userResource = new Resource('http://example.com/users/001')
userResource.delete()
Important point is resource representation is completely independent from state of resource. Client can request representation based on it own requirements. This approach enables multiple format consumption support at server end serving same resource in multiple formats (i.e. HTML, XML). Its like enabling web GUI and web service interface for the resources.
Another important REST principle is statelessness of server, each transaction between client and server to be self contained so that server need not keep track of served client and consecutive requests from same client can be served by different server resources, making better use of available system resource and easier replacement of failed units. Imagine no more memory hogging client session, but this does not mean REST does not allow stateful design, state can be maintained at client end, in other words client is responsible for providing complete request including authentication info each time, on server session or no session, cookie no cookie, server provide same resource state to each client. This also enhances “cachebility” of resources to reduce network hopping.
Summing few advantages, offers better support for load balancing with implicit statelessness, high level of client server independence, does not need separate directory mechanism due to single resource identification scheme, layered design support. In real world, Amazon S3 and blogs are great example of RESTful service implementation.
With some much attention around REST, EE6 has proposed to include JSR311 -JAX-RS: The Java API for RESTful Web Services. This API will enable developers to rapidly build Web applications in Java that are characteristic of the best designed parts of the Web. This API promises to make RESTful web service development easier to abstract away low level details much like JAX-WS does for SOAP protocol.
Though REST promises a lot, but as we will see more and more business implementation, actual value of investment will start appear so will the issues. As it proposes data centric approach thus there is a learning curve in thinking solutions in terms of resources and their state. It is easier to model simple read around REST but complex business scenarios yet to be tested, there are still lessons to be learnt and only time will tell whether all gaps are filled or should we start looking for another new approach.
Post a Comment