When building a service-oriented architecture, it's easy to get stuck thinking about the most general way to represent the domain entities and behaviors that are controlled by a particular service. The truth is, we rarely use services in general ways—we usually combine calls to multiple services and use the responses to create a new, aggregate response body. We often make service calls in ways that resemble how we used to aggregate data from a database, so we have to think about relationships between disparate types in our system and how best to model data dependencies.
We also want to make client development easy. When designing general-purpose APIs, it's easy to get stuck thinking about the right way to do things (if you've ever heard someone critique an API design as not being RESTful, this might sound familiar) instead of thinking about the easy way to do things. A service isn't much good if a client needs to make dozens of calls to it in order to get the data they need....