It seems like a really common use case where<p>1) The service wants to keep its API general, and not client-aware<p>conflicts with<p>2) The client wants to assert a client-specific spec on the returned data<p>(e.g. the track tags, etc)<p>One of the other possible options would have been to keep the general API and then have a separate client-aware bespoke service that consumes it, and serves as the intermediary. Back in the SOA days they called this &quot;service composition&quot;. There are real tradeoffs there though, in that you also want to avoid fully synchronous (nested) service-calling-service scenarios because then latency and SLA becomes the choking point. Caching doesn&#x27;t fully solve that. More reactive architectures start to help out at that point, where consumers are not necessarily waiting for the full response before they take action.