6 ms·
OP here. Indeed. And importantly, this API makes it possible to restrict the query to a list of documents that the client doesn't already have from another sou
by wycats 13y ago
OP here.
Indeed. And importantly, this API makes it possible to restrict the query to a list of documents that the client doesn't already have from another source. In practice, once you start using compound documents with an identity map, there are many cases where existing documents exist on the client and shouldn't be re-fetched.
One really simple example is having a number documents that are related to "people" documents. For example, imagine a blog with blog posts and comments, each of which point at an author. When a list of comments for a post is downloaded, each comment will point to an author. Some of those authors will be the same, and some of them will already have been seen from previous posts. This structure allows the client to request only the authors that have not yet been seen (and if you're lucky, it may even be the empty set!).
- 1qaz2wsx3edc 13y agoYes, the first point is valid, data could be re-fetched. Compounded documents or unions/nested data should only be avoid. I think strong normalization is a good idea. In the second case. The flow could be: GET /posts GET /posts/1/comments GET /posts/1/comments/authors Comments only need to rel to authors, which can be loaded next. Data-binding for the win. I'm not against embedded data as an optimization. It's difficult to fit.