Yeah. The descriptions are a little vague, but what it’s describing is essentially CRUD; Create, Read/Retrieve, Update, Delete.
If you search “REST CRUD” you’ll find a ton of resources.
If you look at this forum it’s a perfect example of client managed resources that utilise the CRUD architecture.
CRUD is related to PUT, GET, POST, etc…
What he’s talking about are “resource” types. I don’t think I’ve ever used “store” archetypes and to be honest never really thought about my other stuff in strict terms… so I’m not sure I can help.
That’s what general discussion topic is for. Anything.
Says this is so when you mouse over it…
Yep, plus it’s all directly on topic for the thread in my opinion.
Reading more on that
so to me, it appears that “store” is a sub-collection.
so could be the “friends” list or “posts”:
`/users/{id}/friends`
`/users/{id}/posts`
so that a user can add/remove his friends or posts on his own.
So here rise another question to me, when I have REST endpoints that look like
`/users/{id}/friends`
`/users/{id}/posts`
from a REST JSON model perspective does this indicate that “friends” and the “posts” collections should be embedded fields inside the “users” collection or there is no such rule?
“store” as explained seems more like “bookmarks” in the sense that the user will not create these resources only associate them with the store. So friends, yes. Posts, probably not since that is a resource controlled elsewhere. “favoritePosts”, yes.
I’m not sure what you mean.
I mean when I have
`/users/{id}/friends`
`/users/{id}/posts`
then does it mean that I should embed friends and posts
into my User document (in MongoDB) like this?
{
"userId":"xxxxxx"
"userName":"MyName"
"email":"myname@yahoo.com"
"encryptedPassword":"xxxxxxxxx"
"friends": [] // List of friends Id ref
"posts": [] // List of Post objects
}
I think stores will only contain references but how you structure that in mongoDB would depend on the cardinality of the relationship, I guess.
…but stores do sound like they’d be a list of IDs/URLs.
Ok, this explains a lot, thanks.