We've been struggling with a few slow API's lately, requiring to refactor soon. Response times of +5 seconds are not unusual. The primary usage of said API is to provide content to fill the page of the client server. The microflow logic behind some of those API methods are like 'one size fits all'. We have made many sub-microflow for each entity to provide everything that is necessary. And after a while, more of those became tangled, into a bunch of spaghetti-mapping. It doesn't only return the resource you are looking for, but also each child object and it’s child objects. Some of those childs you need, some you don’t. And sometimes even back and forth. It's like requesting a list of orders, but receive a list of orders with all orderlines, associated customer, address, list of all customers orders, etc. This has made me think about using a MVC approach, creating a single non persistent entity per page. So if we have two pages that show both orderlines, but with a few columns different, both get a separate entity at the API that only includes everything necessary. It creates a bit of a single responsibility. If a page is broken, all you need to look at is that little bit of encapsulated logic, since it is made specifically and only for that page. This feels like a huge change and maybe more mindset than a programming change. But maybe it isn’t so strange, because basically all the API does is providing the information to fill the page. Maybe the MVC approach is a much better option. But I was wondering if such approach is actually common? Instead of requesting a resource, you basically request the contents of a page.