Modularity in mvc, how best to implement?

Question

Design patterns

We develop a system on backbone.js + slim.php
They both support REST requests, we use the approach of generating url requests for ajax using "/"

GET "/users/45"  // вернет из базы юзера 
POST "/users/"  // создаст нового

There is a lot of information on these examples, but they are all simple. As soon as we encounter real projects (and not todos), we get problems.
What to do when the same entity (for example, user) is found inside many containers, and at the same time, depending on where we connect the user entity, we need certain data.
Question number 1
Create a model for each view? For example, the user in a comment is different from the user in the friends list. Even more different from the user model on the profile page - there is much more information to display. It turns out for each entity 20 models?
Question number 2
How can we then connect and select certain data on the slim-backbone bundle within the /user/id system?
It turns out that for each entity you will have to create a lot of models, views (well, without the latter, nowhere).
Is it normal to approach this format:

• users/45 - get the full user model
  
• friends/users/45 - get cropped model (name, link, url pictures)
  
• reports/7/users - get a collection of users who made report #7
  
• reports/7/users/45 - get the data model of user #45 who made report #7
  
• reports/7/users/45/files - get a collection of files that user #45 attached to report #7
  

Or choose 2-3 models for each entity (detailed, short version) and select them?
What can you read on the topic for building architecture?
ps: after several unsuccessful similar visits to the design, and lost weeks in development from stillborn projects, there was some kind of fear of making a mistake.

Answer 1

Create a model per view?

A model in the context of MVC is not a model of individual entities, but a model of a part of the system (or the entire system) that is needed for this particular view. That is, imagine the "model" of the system as a certain object, inside which there are other objects that work with third ones, and so on. Such is the hierarchy. So the views each connect to their own piece of this hierarchy, and in fact, apart from this point of contact, they don’t know anything more about the system. They have a very limited understanding of the system and do not need to know much.
So. In REST, a "view" is a representation of a resource. And they should not (although they can) be a projection of the tables in the database.
There are several approaches here, the main one is not to take a steam bath and simply, within the framework of a certain resource, palm off that piece of entity data that is needed. Still, it’s easier not to shove something into json than trying to get something that isn’t there.
There is also an approach described in the jsonapi.org standard, where you have additional options in the query string that allow you to "include" certain groups of related resources, etc. This gives us some flexibility in terms of working with the API, but in the case of mobile applications, for example, there are some nuances.
Then write tests, at least at the application level. Then you will stop being afraid to fix / change something. And since you have no experience in designing such things, you will have to fix your mistakes.