You are exactly correct about the role of the API here. A problem arises once you have multiple clients, each with different views, as well as different version

You are exactly correct about the role of the API here. A problem arises once you have multiple clients, each with different views, as well as different versions of those views. You can end up with a proliferation of API endpoints, each serving a custom view object for each different type of view, or you make your endpoints generic enough to serve all views, thus serving more data than any one view will ever use. You'll naturally have a tension between endpoint reusability and specific usefulness. The article actually seemed to have some of that tension itself, saying both "If you only want a subset of that graph, make an endpoint around that subset." and also "[Ad hoc endpoints] aren't REST", without giving any guidance as to how to make endpoints around arbitrary subsets of graph data without descending into being ad hoc. I'm not saying that you can't balance these with a good REST API, just that there is a real tension.