1) The service wants to keep its API general, and not client-aware
conflicts with
2) The client wants to assert a client-specific spec on the returned data
(e.g. the track tags, etc)
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 "service composition". 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'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.
1) The service wants to keep its API general, and not client-aware
conflicts with
2) The client wants to assert a client-specific spec on the returned data
(e.g. the track tags, etc)
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 "service composition". 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'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.