Restful API vs Fewer HTTP Requests

Question

I am working on a new mobile app which will be talking to a rails server. Originally the idea was to remain restful and follow all conventions, however this goes against the client side best practices and performance of minimizing HTTP requests. I was wondering when you should remain restful and make only one api call per resource type, and when should you make one call which will update, add, remove and return a list of a few different resources.

For example, the app I am working on will be a scorekeeping app. Upon login, I return both the user information, a list of games that the scorekeeper can then edit, as well as all of the stats associated with each game. Since this list is returned in the first call, the view is immediately changed to the game list which is already pre-populated. This is quite fast.

Now from my understanding, to remain restful I would have to first make the login call(POST) for the user information, then make another(GET) call for the games list.

Another example would be uploading stats. Each stat has an action associated with it, whether its delete, update, or create. Currently all the stats are stored in a JSON which will send one POST call to the server. The server will then loop through the list and delete, update, or create the stats as needed. Now restfully I should be making a separate POST, DELETE, or PUT calls for each stat correct?

I have a good understanding of what restful is, but I'm failing to understand when/why to use it, and when to just combine everything into one api call to increase performance for the end user.

Answer 1

Do you have (a) an actual, measured performance problem, (b) a good and well-thought out argument for why you will have one, or (c) a vague concern that REST is chatty?

It sounds like (c). Yes, REST can be chatty. Usually that's addressed with caching and good endpoint design.

Now from my understanding, to remain restful I would have to first make the login call(POST) for the user information, then make another(GET) call for the games list.

That would be traditional. It would not be unreasonable for the initial POST to do a redirect to get the games list. You can perform the GET conditionally (If-Modified-Since, If-None-Match), which will save bandwidth and server time. You can also set an explicit expiration time for the result of the GET to save some calls to the server.

Another example would be uploading stats. Each stat has an action associated with it, whether its delete, update, or create. Currently all the stats are stored in a JSON which will send one POST call to the server. The server will then loop through the list and delete, update, or create the stats as needed. Now restfully I should be making a separate POST, DELETE, or PUT calls for each stat correct?

In this case, it sounds like the verb you want is PATCH. You can invoke PATCH on a collection endpoint, such as /stats, and include all the updates in one call. I suggest using the structure defined in RFC 6902 for PATCH requests.