There can be a bit of tradeoff here, depending on the granularities of the dependent entities, and the design of the backend storage system. One problem is latency; the dependent entities cannot be requested for at least one RTT ;if there are chains of depencies then this can quickly add up (HTTP/2.0 can reduce this effect somewhat). If most of the dependent entities are used most of the time then it can be more efficient to send a dataset containing multiple entities. This is especially true if the data is compressed (either ahead of time or on-the-fly). Most compression algorithms require a bit of a run-up to get started. This is very much the case for RDF - especially n-triples / n-quads, where there aren't any prefixes, and for RDF/XML, which is XML... This does not lessen the importance of making the other entities available by name (blank nodes must die). [If the client requests an RDF format that supports named graphs then each entity can go in a separate graph. This can help with caching]