This is a pattern I’ve used in practice. Whether you call it a format, a view, or some other synonym, it’s a simple pattern to apply. In my experience, many times consumer inquiry needs fall into a few common buckets. Make each one of these a “view” or a “format”, and this is easily done.

The important actor in doing this right, however, is to understand the consumption patterns needed. Too often, API teams simply create a “summary” and a “detail” view where detail has everything. Invariably, teams go, “I need the summary plus these other two properties” and over time, the differences between “summary” and “detail” get very blurry. Understand your consumption use cases first, understand where returning certain things can have a significant impact on response times, and make thoughtful design decisions.