> Ok, but an order has an array of order lines, and each order line has sub-arrays as well, like details of the packages it was shipped in etc. > So that might

> Ok, but an order has an array of order lines, and each order line has sub-arrays as well, like details of the packages it was shipped in etc. > So that might be 5-10 calls to get an order line, and for a few thousand lines we're looking at several tens of thousand calls to get a full order. You definitely need to pick and choose the granularity you offer. There's a level of normalization in data structuring that approaches absurdity and this would be a good example of an absurd case. It is however an excellent demonstration of why making overbroad "you must never do X" rules is dangerous. I think a decent test is to ask yourself the question: "How much data is here that I don't need?" In the example referenced, if I'm looking at the full order history, I probably want to see only summary/header data with the option to view the full order details, so it wouldn't make sense to return to the user potentially a hundred thousand order lines' worth of data just because they're trying to view their history. If I then want to view the /orders/:id for one specific order, at that point it does make sense to return all of the related lines, shipment details, etc.