How many other clients to this API will there be?
If this is the only client, why not. Its use case is tailored to just this usage, just this representation. Assuming your client isn’t trying to be smart and load/cache the object across end points, this can be a very efficient way of writing an API. When your client changes its easy to cleanup old code paths without worrying that somewhere else is also using the end-point.
If you have more than one client, this strategy starts to become problematic. One size never really fits anyone, and a bespoke fit even less so.
You could possibly provide tailor made api-endpoints for both clients, but now you run into the fact that some end-points are duplicates (to keep the one to one mapping), and others have such small differences you might have to read the code very deeply to spot it. But this strategy quickly becomes more difficult the more clients are added, and the business will quite rightly ask what is the difference between supporting 1, 2, or 50 clients? <Insert Name of a Titan Software Company> does it!
Once you get to your second client you really should be looking at refactoring out the commonalities. There may still be some bespoke api end-points for just this or just that client and use case, but the API should be moving toward orthogonal and composable calls. This API will oversupply detail for some views, and other views need to combine data from several API end-points, but those API’s will be generally useful to most clients, and much fewer in number simplifying support and maintenance.
Alternately give up on REST and transition to a stateful communication model using websockets – a complicated solution that has pay offs in some scenarios. I don’t recommend it for you situation as it appears though.