I'm trying to understand what is the best way of migrating a website that works in a single layer and gets all the data via an ORM, to one that uses multiple layers, using an API backend to get the information needed to display a page.In the project I'm working on, we have code like this, where data is retrieved via a Doctrine ORM:$accountAddress = $sfUserProfile->getCustomer()->getAccount()->getAddress();Doing a naive translation of that to an set of API calls would result in 4 api calls. Although they may not be that slow individually, if we made one api call for each DB access that we currently have it would be incredibly slow.That could be changed to a far more specific call like:$backendAPI->getAddress($sfUserProfile);which would reduce those 4 API calls down to a single one, which is better. But it still leaves all the other queries that would need to be run for that page to be converted to separate API calls. I could write an api call that gets all of the user information required to display the user account information page in one go:$info = $backendAPI->getInfoForAccountPage($sfUserProfile);Where $info contains a set of simple entities (not ORM entities) e.g. :$info = array(   'customer' => $customer,   'account' => $account,   'accountAddress' => $accountAddress);(Or probably I'd create for each page a specific 'info' class toenforce clarity on what info is available).Is it 'correct' to write really specific API calls? Or what is the preferred method for avoiding having to have too many API calls to display a page?The specific API call way seems sensible when there is a small known set of data that needs to be retrieved to display a page, but it seems like it might lead to having to write a lot of API end-points, so is there a better way of handling the problem?
Migrating single-layer ORM based app to multi-layer API
api design;orm;n tier