Is a particularly noisy HTTP API really the fault of a RESTful design? The principles as I understand them should have little effect on this [1].
If something requires multiple API calls when it could just require one, this points to the the resource being too finely-grained and ill-fitting to the behavioural domain of the client.
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.
> "To ensure that security (and integrity) constraints are met, REST applications need to contain error prone code that compares the before and after states to check if the transition is legal."
Can you expand on this? I've not run into similar problems myself.
[1] RESTful Web Services correctly inherit and use HTTP as their interface.
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.
Exactly, this is just the case of a poorly-designed, lazily-implemented REST API. Good APIs generally can't be auto-generated from some ORM model definition, which is what it sounds like the one mentioned in the OP did.
If something requires multiple API calls when it could just require one, this points to the the resource being too finely-grained and ill-fitting to the behavioural domain of the client.
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.
> "To ensure that security (and integrity) constraints are met, REST applications need to contain error prone code that compares the before and after states to check if the transition is legal."
Can you expand on this? I've not run into similar problems myself.
[1] RESTful Web Services correctly inherit and use HTTP as their interface.
[2] http://en.wikipedia.org/wiki/Domain-driven_design