Thursday, October 8, 2009

Resource Oriented Architecture - Part 3 (Addressability)

URLs is one of very simple and powerful feature of WWW. It is because of URL that everything is discoverable and locatable on the web.

e.g. a builder putting his URL on an advertisement bill board and everyone who hits that URI gets access to all the resources about a project which builder has put on the web.

If we look at a search results of google each page of the search results is a resource and each page has a unique URL.
e.g. http://www.google.com/search?q=India&start=35 will take me to a page which would have the search results for the query "India" and the page contents would start from 35th search result.

In a resource oriented world each resource inside a system would have a unique URL to locate it. e.g. in a CRM system all the accounts would have a unique URL to navigate to them. Which basically means that all the accounts are addressable. If we shoot a "http GET request" to that URL we should be able to get details about that account.

So an account with ID=1234 can be represented as http://crmsystem/account/1234
Even a collection of accounts is a resource e.g. all the accounts from Hyderabad can be resource found by sending a http get request to http://crmsystem/accounts/hyderabad
Note the subtle difference between the URLs. The first URL contains the string account while the second one contains accounts, which signifies that the first resource is just an account while the second one is a collection of accounts.

This approach is very different from classic SOA applications where we'd write 2 web service operations called getAccountbyId(string accountId) and getAccountsForRegion(string region). Both the operations will have a single URL which would be http://crmsystem/services and can be invoked by sending appropriate SOAP envelope to this URL using http POST method. Its not really intuitive for a user or a machine as to what kind of POST requests one is supposed to send on the URL.

Another important aspect to note about this tenet is that a URL is non-ambiguous and can point to one and only one resource, while a resource can be located by using 2 different URLs. e.g. an account with accountId=1234 which is a top performing account can be represented by 2 different URLs i.e. http://crmsystem/account/1234 and http://crmsystem/account/topPerformer. In this case the URL http://crmsystem/account/1234 points to a static resource and ideally won't change while http://crmsystem/account/topPerformer is a dynamic calculated resource and can point to different resources at different times.

This tenet will closely relate to the next tenet i would discuss in my next post in this series i.e. Uniform Interface.

~Abhishek

No comments: