Introduction
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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access