3 ms·

What if I've selected 5 arbitrary people to unfriend? `PUT /friends/???.json`

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 ago
  Yes, 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.
1qaz2wsx3edc 13y ago
Think of it like you're trash bin, you move the files there, one at a time, then empty. State is captured. Then invoked. This is only necessary for transactional requirements. Another method is having a collection sorted and slices. DELETE /teams?id[gt]=10&id[lt]=13 As for non-sequel ids or random ids. It could be possible to support ?id[]=12&id[]=9&id[]=4. Sure it could be /teams/1,2,3 this is just a small detail of the parser. I'm more interesting in how a collection is queried and represented.
- wycats 13y ago
  Actually, the current Ember Data protocol uses ?id[]=12&id[]=9&id[]=4. There's no good reason for the extra verbosity; it's pretty easy to split over commas and the current format is tricky to parse for platforms that don't already understand it.

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 ago
Yes, 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.

1qaz2wsx3edc 13y ago

Think of it like you're trash bin, you move the files there, one at a time, then empty. State is captured. Then invoked. This is only necessary for transactional requirements. Another method is having a collection sorted and slices. DELETE /teams?id[gt]=10&id[lt]=13 As for non-sequel ids or random ids. It could be possible to support ?id[]=12&id[]=9&id[]=4. Sure it could be /teams/1,2,3 this is just a small detail of the parser. I'm more interesting in how a collection is queried and represented.

wycats 13y ago
Actually, the current Ember Data protocol uses ?id[]=12&id[]=9&id[]=4. There's no good reason for the extra verbosity; it's pretty easy to split over commas and the current format is tricky to parse for platforms that don't already understand it.