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.
July 17, 2020, 8:38pm
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.
July 17, 2020, 9:19pm
That’s what general discussion topic is for. Anything.
Says this is so when you mouse over it…
July 17, 2020, 9:31pm
Yep, plus it’s all directly on topic for the thread in my opinion.
July 18, 2020, 8:31am
Reading more on that
so to me, it appears that “store” is a sub-collection.
so could be the “friends” list or “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
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?
July 18, 2020, 10:26am
“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.
July 18, 2020, 10:43am
I mean when I have
then does it mean that I
should embed friends and posts
into my User document (in MongoDB) like this?
"friends":  // List of friends Id ref
"posts":  // List of Post objects
July 18, 2020, 10:52am
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.
July 18, 2020, 11:14am
Ok, this explains a lot, thanks.