Map your API model to the way your data is consumed, not your data/object model
I'm glad this was brought up. I feel I'm constantly battling with myself on this issue. The purist in me always wants to create REST endpoints that return just the minimum info you'd expect from that URL which represent my model perfectly. The result is requiring customers to call the service a lot. But sometimes if you take a step back and think about how it will be consumed you can really do your consumers/customers a favor. Although, if not carefully thought through you could end up doing more 'work' and returning data that is always discarded from the response.
This thinking can however also be taken to far. The Dutch Railways recently released an API for all their trip planning, live departures and pricing info. Unfortunately, it's mainly a way to get at the API their apps call: it's all presentation based.
For instance, up until recently there was no way to tie a certain train service listed in a given trip to the same service in the live departure endpoint. It's also still not possible to tie a train service to its schedule.
They've taken their API and made it all consumer-oriented and it's gone overboard.
I'm glad this was brought up. I feel I'm constantly battling with myself on this issue. The purist in me always wants to create REST endpoints that return just the minimum info you'd expect from that URL which represent my model perfectly. The result is requiring customers to call the service a lot. But sometimes if you take a step back and think about how it will be consumed you can really do your consumers/customers a favor. Although, if not carefully thought through you could end up doing more 'work' and returning data that is always discarded from the response.