I'm working on a new iOS app project, on the mobile side. Some architecture changes are happening and it turns out we will have to rely on a custom built private API that will be used by the app we are building and also by other clients such as a website.
The API being designed follows the Rest style of resources-centric URI and CRUD operations mapped to HTTP verbs. things like:
GET www.example.com/books DELETE www.example.com/books/482094 POST www.example.com/users/6793
The problem is that this style often leads to the need for the mobile client to do many requests for loading a single app screen or managing a single user UI action. This leads to the app being in loading mode for 8 seconds till it has everything needed. A slow and unresponsive app.
Mobile clients have serious limitations when it comes to connectivity and so ideally, we should follow that sort of rule:
1 screen == 1 API call
1 save == 1 API call.
There are many situations where this puts you on a collision course with the REST design principles, for examples:
- let's say your app has been offline for a day and you need to sync
with four tables of the back-end databases and you need a call like
- let's say there is a screen where the user can edit many of his objects, for example ticking tasks in his todo list. There should be a way to edit all those tasks records in one single batch API call rather than one API call per edit.
- let's say there is a screen that mixes information from the ORDER, SALESMEN and PRODUCT db tables, I should get that data in one call instead of three.
the risk is that we might end up with the most Restful API there is and also the most useless unresponsive mobile app there is.
The thing is I'm only a new contractor there and what I need is something that help me makes those points, some articles from well respected sources or something like that. Major players compromising with the REST style for their mobile client (e.g.: by using composite aggregate API end points).
Or any solution for this general problem. Thanks!