Nested or separate entities in API?

Question

API

I never really thought that the API can have not only a different implementation in terms of response codes, errors, etc., but also structures. This is not about the REST API, but more about the command API.
Example: client. It may have shipping addresses. It is logical that without a client, addresses are not used anywhere as a separate entity. It is quite possible to invest them inside the customer. Another example: there are orders, they may have an invoice, which, although they are associated with orders, can and are used.
So, an invoice can be attached to the order entity or a separate endpoint (command) can be allocated for them.
On SO, for example, they write that everyone should decide for themselves how to implement. If you look at js-frames like react and vue, they even made a special normalize lib to work with the resource without nesting. They say it makes life easier.
Which API do you prefer during this difficult time?

Answer 1

and it’s not very clear why they mutually exclude each other
, I get a list of trading strategies with instruments nested in them,
while the list of instruments is available separately,
I could request a separate list of strategies, then for each of them an instrument by id. Well, this is more requests both via http and in the database
, however, I have the opportunity to get the tools separately and by id, and with one list
, you can really spread the reasoning for a long time and, in the end, we will come to the same as on SO