REST applications: Identifying resources

One of the first step in designing a REST application is to identify resources and define their representation. Oft heard advice in this regard is "nouns are your resources". Go through your application and its requirement/use cases, identify all the nouns, model them as resources and use HTTP verbs on these resources to add their operations. GET is to get the resource, PUT is to modify the resource, DELETE is to delete the resource while POST is to be used to create a new resource.

However, this only serves to arrive at the 1st set of resources. It has to go through multiple iterations wherein this initial resource set is refined to add/prune/modify to arrive at the final list of resource. Often it helps to run the list through a few questions.

Which resources are important from client's point of view ? All nouns or entities that are used internally inside  an application behind the scene may not be relevant to clients and so shouldn't be part of resource list. At the same time there would be a number of not-so-obvious resources. Some applications may like to expose some derived information to client as web services,  an example would a valuation calculator that provides calculations like average,standard deviation, percentage against ceiling or floor values. Thus "ValuationCalculator" can be modeled as a resource.

Can all actions/operations be handled by using HTTP verbs on existing resources ? For example in a banking application how to handle an AccountTransfer operation wherein an account is transfer from one branch to another. As this operation involves changing the representation of Account resource, we can add an attribute branch to Account resource ( this attribute can be an URI of Branch resource). Then we can apply PUT verb on Account resource to implement AccountTranfer operation.

However some other actions are more tricky to handle. For example - processing of account opening  application in a banking application. Which resource should handle this operation - Account, Customer, Branch. Herein, we need to introduce a new resource - AccountApplication which will have an status (with possible values of approved, declined, under process, on hold etc.)  attribute in its representation. Thus as the application goes through varied approval processing, PUT verb can be applied on AccountApplication resource to keep track of status.