REST API Design: Multiple calls vs. single call to the API

Question

We are developing a Rest API for eCommerce website which will be consumed by mobile apps.

In the home page of an app we need to call multiple resources like Sliders, Top Brands, Best Selling Products, Trending Products etc.

Two options to make API calls:

Single Call:

www.example.com/api/GetAllInHome

Multiple Calls:

www.example.com/api/GetSliders
www.example.com/api/GetTopBrands
www.example.com/api/GetBestSellingProducts
www.example.com/api/GetTrendingProducts

Which is the best approach for rest api design - single or multiple call, explain the pros and cons?

Which will take more time to respond to the request?

Answer 1

In Theory the multiple simultaneous calls are more flexible and just as fast.

However, in practice if you load a page, and then load each part of that page, displaying loading spinners all over it until you get the results back the result is slow and disjointed.

For this reason AJAX requests for data should be used sparingly and only when you have a section of the page which is slow to load or needs to be refreshed on a different cycle to the rest of the page. Say a master/detail display, where you want to select an option from the master and display the corresponding detail without reloading the master.

A common design is to keep the separate APIs for coding flexibility and micro-service concerns, but combine the data server side in the website. so that the client needs to make only a single call to its own website. The API calls with appropriate caching should be fast within the data center.

Also, consider having NO client API calls at all. simply generate the HTML server side. Although javascript single page app frameworks push you down the api route. It's usually not the optimal approach for high volume e-commerce sites.

enter image description here

• Shaiju T: Thanks, Actually This api is consumed in android and i phone apps, i want to know when app home page is loaded should i get all resources like: sliders, brands, products in single api call or make individual call to api for individual resource when users scrolls down ?
• Ewan: The same logic applies, minimise the simultaneous calls where not required. An app gives you a bit more flexibility to download info in the background though. You might want to switch to a GetChangesSInce(date) approach
• Shaiju T: I have last question how would apps like amazon , flipkart work ? Doesnt they load all home page resources at single call when user opens the app ? I am want to know what would be best approach on this.
• Ewan: yes, you can see amazon for example, loads a full page of products, then has separate calls for the user specific items, such as recent searches. this allows them to cache most of the page
• Ewan: add a new backend endpoint which combines the two operations and call it once from the front end

Answer 2

TL;DR: All other application considerations aside, performing a single call would be faster than performing multiple calls. Running the calls asynchronously may cut down the overall time needed to complete a given operation from the perspective of your user (which might well be all you need), but in aggregate, the time taken would still be longer for multiple calls.

In your case however, i'm not sure that's the full story.

REST APIs are a slightly ambiguous term, due to various interpretations of the paper that made the idea popular. By even the most liberal interpretation of what constitutes a REST API however, what you have doesn't really fit.

The core principle is that you have a resource on which you want to perform an action. The URI identifies the resource you are interested in, and you would normally use the HTTP verbs to indicate what you want to do to that resource.

In your specific case, all of your methods have the word 'get' in their name. You should be changing the verb used in the HTTP request to indicate that you want to 'get' the resource available at that location.

Your URI scheme should represent the logical hierarchy of the resources you want to make available to the users of your API, so in your case i would consider using something like /api/products?category=sliders to filter down your collection of products. This means that when clients want to get all of your products, they can simply omit the query string.

• Shaiju T: Thanks, so you mean single url for API but request should to different resources be made using Query String ? , also check this.
• richzilla: Yes running your calls asynchronously would reduce the absolute time needed to fetch the data, but in aggregate, the time taken will still be greater; More calls have to repeat the overhead of a TCP connection, and a communications round trip. Even using features like keep-alive arent going to remove this entirely.
• richzilla: Category would be a property of an individual product resource. Logically you would be fetching a collection of products and filtering all those with the specified category
• Shaiju T: so you mean , when the user opens home page of the app , one call should go to the api which returns all resources mentioned above ? or when he scrolls done individual calls should be made for specific resources which is best practice?
• richzilla: It depends on what your user expects to see at each point in your application. Take this website for example, when you click on questions you see the URI is /questions, when you click on one of your favourite tags, the URI is /questions/tagged/<tagname>