I'm writing a REST API with Mongo and was intrigued by the whole document modeling strategy. It seems like a very divisive issue where people say to denormalize first, then normalize or vice-versa.
I'm interested to see how the resource structure of a REST api influences the structure of a document-based db. It seems like with a REST api resource structure, it almost makes sense to have separate collections for everything (i.e. locations, tenants, transactions) although this seems like it would be working against one of Mongo's benefits.
My question is how would you model the resources of a REST api in a NoSQL (specifically Mongo) document database.
The answer is, there are many ways, depending on what you want to optimize on. Generally, the defining of your document schemas and separation of collections will depend on what your specific use cases for the documents are - how will you consume your data?
One big concept to remember, is that "Joins" between collections are costly - basically you're getting a foreign key from one collection and doing a whole other lookup in another collection, which is why de-normalization generally helps performance - if it matches your use cases. This is where MongoDB has the potential to shine, although in the future if your requirements change, your document structures could potentially need to change dramatically.
A second key consideration, is the MongoDB document size limit - roughly 16MB last time I checked. Take your classic blog website example, with a blog posts collection. We can choose to store comments as subdocuments, as an array in the post document. This way, you could have a rest API for /posts/postID, returning you the post document without having to do any "joins" or lookups in other collections for comments and so forth. But then you run into problems, if you have posts with humongous amounts of comments on it, so in that case, you would have to normalize your data by separating out comments into another collection.
So, speed / ease of retrieval from the database and the flexibility of your document storage - should you need to change a document's schema structure for the future, are two major considerations you should think about as you plan a project API out.
Ask yourself, how does document/collection X going to be used? When would you need to retrieve data from it? If one resource tenants has a "parent resource" location, and accessing location is the only time you actually need tenants, then by all means you could potentially design the storage of tenants into the schema of location. But if you need to be able to query tenants by themselves, then you probably want to break tenants out into their own collection. So there's no right or wrong ways to go about it, just base your planning on how you plan to consume your data!
Good luck!