Ah, I see. Just so you know where I'm coming from -- I wouldn't even attempt service design in the absence of a real service customer. When such a client exists, I try to design an API to answer the specific questions it's going to ask, hopefully at the level of abstraction that it expects. Sometimes that's simple CRUD operations, but I often find that simple CRUD layers on models are too low level and that implementation details unnecessarily leak out into the API. So I'm much more hesitant to expose CRUD operations on models simply because we have them.

At the end of the day, I feel that APIs are promises, and like promises, they're a whole lot easier to make than they are to keep. The longer-term performance concern raised by one of the views in the original version of this PR is just a trivial example -- to properly accomodate, it would have required additional complexity on both server and client. There's also simple bug fixing, security, URL/ID permanence, permissions, how to map concepts when things get deprecated, and whatever else. For any given call, that cost might be reasonable, but it adds up quickly. That's why I'm so fixated on making sure there's a concrete, real use case driving every API call that we expose.