I'll go further and elsewhere at once: APIs should not present nested objects but normalised data. It enables clients to easily to lay out their display structure independently of API resource schemas and eases out tricks like diffing between subsequent responses, pulling updates or requesting new data by passing IDs and timestamps of already known data, etc. API normalised data obviously shouldn't correspond to DB normalised data. Nested objects are superior only for use with jq.

> APIs should not present nested objects but normalised data

If something is nested, let it be represented as a nested structure. I find flattening causes more mental overhead. If something is too flat, it becomes less obvious what data is exactly necessary to do what you want to do