Here is the approach I used in my session at the Colorado Software Summit on REST (I will post the slides over the weekend) to find resources.
- Domain Nouns: This is the most natural approach for finding resources, but it can end up with an inconvenient resource model. For instance, the NYT Movie Reviews API has things like Movies, Reviews, Critics, Critic's picks, Reviews by reviewer identified as resources. These can provide a good starting point, but may not meet the needs of client apps, which leads to the next step.
- Composites: These are combinations of other resources, created primarily to address client app needs. Composites can also fix the urge for batching. An example is "a user profile with 5 contacts plus favorite colors plus 10 latest updates" identified as a single resource, so that the client developer can get with a single GET.
- Tasks and Processes: An example is an account transfer with some back-end process to complete the transfer at the end of the business day. Some in the audience wondered if it is RESTful to identify such an account transfer "process" (something that is typically identified as a verb). But why not? Such processes can be resources themselves with their own state and lifecycle.