Resource Oriented Architecture - Part 4 (Uniform Interface)

The RPC style services are very good in creating and documenting the contract. However if i look at it from a high level view i am creating a new interface for every service in the world.

Imagine this i can write so many services to manage a CRM account e.g. createAccount, updateAcccount, deleteAccount, addOppurtunity, winOptions, looseOptions so on and so forth i.e. for every conceivable action i want to take on a account i can probably create a new method in the contract. This becomes so difficult to manage when orchestrating the services to come up with a business process. Because its very difficult to understand what services can be called at what stage in a business process.

Now when i give this to a programmer who's building an orchestration using these services. There's no uniformity in the interfaces which allow the programmer to come up with a pattern or a way to know what might be possible in the system. One has to be a domain expert to work with such a system.

That's why ROA proposes to have a uniform interface which should be exposed by the resources inside a system. i.e. once you know the URL of a resource it can support upto 6 methods which are nothing but http verbs. Let's have a look at them

1) OPTIONS :- This is a metadata based verb, i.e. it is supposed to tell the caller as to what all http methods does the resource support.

2) GET :- As the name implies this would return the resource content to the caller. The format of content is another story and we'd discuss in the next tenet.

3) HEAD :- This is supposed to return the http header information to the caller. e.g. when was the content last modified. This is an important verb as based on this we can take advantage of http caching infrastructure.

4) PUT :- This verb is supposed to create or update a resource. Ideally if the request is sent to a non existant URI then we are supposed to create the resource while if the resource exists on the server then it is supposed to be replaced by the new one

5) DELETE :- As the name implies, it can be used to delete or archive the resource.

6) POST :- This is one of the most open ended verb which has been left out in http and hence the most abused one by SOA. Anyways in a ROA this verb can be used either to append content to an existing resource or to create new content where the URI of the newly created resource would be defined by the server.

All in all we can conclude that a resource can support CRUD operations using PUT/POST, GET, PUT/POST, DELETE http verbs, while a resource can define the supported operations using OPTIONS http verb. HEAD is a verb which can be used to take advantage of caching mechanism.

Now once we've this kind of system in place we've to ensure that we define our system in such a way that each entity, state or a stage of business process can be represented as a resource. So in our example of CRM system we can create 3 resources i.e. Account, Oppurtunity, Option

and then both these resources can support GET, PUT, POST and DELETE operations. So createAccount becomes a PUT request to http://crmsystem/account/myAccount/1234, deleteAccount becomes a DELETE request to http://crmsystem/account/myAccount/1234,

addOppurunity becomes a PUT request to http://crmsystem/account/1234/Oppurtunity/1,

winOptions, looseOption can become a POST request to http://crmsystem/account/myAccount/1234/Options/1

The beauty of the whole system lies in the fact that each entity has a URI and each URI supports a uniform interface. So when i give a URI of an opportunity http://crmsystem/account/1234/Opportunity/1) to a programmer in my company, at the very least he knows the following

1) To get the details of the opportunity he has to hit the URI with http GET request

2) To delete the oppurtunity he has to hit the URI with http DELETE request

3) To update the oppurtunity PUT or POST should help

4) To know what is supported OPTIONS can be used.

In this world we literally can live with these verbs and most if not all programming problems can be broken into resources. The business process orchestrations can stream line themselves around these verbs and the world might become much simpler for us as programmers :).

~Abhishek