May Your Application R.I.P – Part 1

[adsenseyu2]

Didn’t really mean that (R.I.P) way, Indeed. 🙂 The objective behind this series of blogs is to represent some of the best practices, the how-tos and the whats/whys in relation with REST based integration of applications.

Before we shall talk on any related aspects of REST and how to design great RESTful services and, why go for RESTful design in the very first place, lets try and understand a little bit on what is REST and,  “Resource Oriented Architecture (ROA)”.

What is REST?

REST is an architectural style for distributed hypermedia systems like WWW. REST stands for REpresentational State Transfer. The term first originated in 2000 doctoral dissertation of Dr. Roy Fielding, one of the principal author of HTTP protocol. System or architecture or design that follow these REST principles can be termed as “RESTful”. The key to REST architectural style are resources which is defined later in this blog. In RESTful architecture and design, an application can be split into resources which can be accessed using a URI. These resources in its current state can be accessed in form of information which is termed as representations. See the diagram below that represents a resource with multiple representations and different operations that can be applied on the resource. In other words, a representation is information about the state of the resource. For example, a book as a resource can have multiple representations. One can be a representation in form of name of the book, its author and pricing details. Other can be the content of the book. And, the recommended way to work with different representations of the same resource is to have different URIs.

Following is what takes place in REST (Representational State Transfer):

1. Client access the resource using URL.
2. Client retrieves the representation (information) of the resource.
3. Once retrieved, client is put into a new state.
4. URLs in the resource data (existing representation) can be used to retrieve new representations and transfer the client to a new state.

Thus, in brief, the state of client changes (transfer from one state to another) based on retrieval of resources’ representations – “Representational State Transfer”

What is Resource Oriented Architecture (ROA)?

In software engineering, a resource-oriented architecture (ROA) is a style of software architecture and programming paradigm for designing and developing software in the form of resources with “RESTful” interfaces. These resources are software components (discrete pieces of code and/or data structures) which can be reused for different purposes…Wikipedia

Designing and developing software in form of resources can be easily understood if we look at the analogy of virtual machines in a physical machine. Virtual machines look like the real machine in the sense that it starts with its own operating system and looks to be having its own CPU, memory (RAM & hard disk),  network cards etc. And, you could work on this virtual machine just like the real machines. On one physical machine, there can be one or more virtual machines (VMs). However, do they have their own CPU, memory, network cards etc? Actually, NO! They use the “resources” of the actual physical machine based on pre-defined configurations and policies setup while creating new virtual machines. Thus, multiple VMs end us using “resources” such as CPU, memory, IO, network etc of the actual physical machine.

In ROA, one can create different services by making use of resources that can be one of software entities such as services, documents, rows in database etc, and which can be accessed using a standard URL. The services are designed and created to deliver the information by aggregating/mashing up information from different resources. That said, would it be right to say that service-oriented architecture (SOA) and ROA can go hand-in-hand? YES, it is. Actually, you could start designing resources on top of existing SOA styled applications.  One of the main differences between ROA and SOA in that in the latter one the single, directly accessible distributed component, represents one or more business functionality that often process different potential resources. Such resources are credited candidates for being considered resources in a ROA, thus deserving to be represented as distributed components.

The key in ROA is to identify what can be termed as “resources”. If done well, you end up creating some good resources which can be used in a great way. The viewpoint of ROA can prove to be very useful in identifying the resources and creating services (SOA) by making use of these resources. The very reason why I explained ROA is that it may be a good idea to consider ROA concepts when planning for REST based integration because it helps you to create good RESTful services based on definite perspective. Lets try and understand the technical nitty-gritties of what can be termed as Resource?

What are Resources?

Simply speaking, Resources are nothing but a representation of information-oriented services, data entities and documents. Resources are represented in form of nouns which is acted upon by making use of operations such as GET, PUT, POST, DELETE etc. The resources have to have at least one URI which acts as name and address of the resource. These resources can be mashed up/aggregated to form one or more applications or solutions offering aggregated & rich content and, delivered as innovative business services. These resources have lifecycle methods such as create, update, delete etc which can be used to access and update the resources.  Dr. Roy Fielding’s doctoral dissertation, “Architectural Styles and the Design of Network-based Software Architectures,” identifies four essential concepts underlying the resource-oriented architecture:

1. Resources
2. Their names (URIs)
3. Their representations
4. The links between them.