The resources attached to URIs do not need to be directly related to the underlying data model implementation. The interface which you provide to a client-side developer should closely match their domain and not just your implementation [2]. Provide useful abstractions.
Great point. I think this is where I get hung up a lot. Its just too much work sometimes to try and imagine how people will consume your API. In a perfect world people should have to ability to mash up your data to create any kind of application they want and so we tend to drill straight down to the fine-grained model. It feels easier since we have already figured out that model, now all we need is a URL structure to also represent it.
But, when I explore creating a model which represents the consumer's domain I feel like its really dang close to RPC. Basically I end up slipping the opposite direction I did before. Why not just make every API call have it's own resource representation? FullCatalogWithAuthors might as well be GetFullCatalogWithAuthors.
Great point. I think this is where I get hung up a lot. Its just too much work sometimes to try and imagine how people will consume your API. In a perfect world people should have to ability to mash up your data to create any kind of application they want and so we tend to drill straight down to the fine-grained model. It feels easier since we have already figured out that model, now all we need is a URL structure to also represent it.
But, when I explore creating a model which represents the consumer's domain I feel like its really dang close to RPC. Basically I end up slipping the opposite direction I did before. Why not just make every API call have it's own resource representation? FullCatalogWithAuthors might as well be GetFullCatalogWithAuthors.