49

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?

Josip Ivic
  • 1,617
  • 5
  • 28
  • 46
Shaiju T
  • 601
  • 1
  • 5
  • 10

2 Answers2

35

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

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • 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 ? – Shaiju T Feb 09 '17 at 09:39
  • 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 – Ewan Feb 09 '17 at 09:49
  • So you conclude, its best to have single API to call for all home page resources response at once when App's home page loads and have different api's for sliders , brands etc seprately for micro-service when you have a section of the page to be updated ? – Shaiju T Feb 09 '17 at 10:29
  • not unless you have a good reason why those sections are not just loaded with the page/main data – Ewan Feb 09 '17 at 10:31
  • 1
    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. – Shaiju T Feb 09 '17 at 10:51
  • 1
    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 Feb 09 '17 at 11:08
  • @Ewan What do you mean exactly by 'combine the data server side in the website' ? Let's say I need an id from an endpoint, in order to get company data using that id, from another endpoint. If I follow a microservices paradigm, I'll have two endpoints and therefore two consecutive calls in the frontend. While gathering the two calls will increase complexity. – Standaa - Remember Monica Jul 27 '17 at 19:51
  • 1
    add a new backend endpoint which combines the two operations and call it once from the front end – Ewan Jul 27 '17 at 19:53
  • Just out of curiosity, now 4 years later, would you answer this question differently, either because of changes in technology or in your approach? – Eyeslandic Jan 30 '21 at 07:49
  • I think now, we would assume a Single Page App design which would allow you, like the app, to load all but one of the datasets up in advance and keep them in memory. However, even then for an Ecommerce site you want performance at all costs. If you can make a page with those dropdowns hardcoded into it and cache it, so no api calls are made, Then that site will sell more per server over xmas than a clever SPA – Ewan Jan 30 '21 at 09:40
15

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.

richzilla
  • 1,083
  • 7
  • 11
  • Thanks, so you mean single `url` for API but request should to different resources be made using Query String ? , also check [this](http://softwareengineering.stackexchange.com/questions/305872/many-asynchronous-calls-vs-single-call-to-the-api). – Shaiju T Feb 09 '17 at 08:09
  • 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 Feb 09 '17 at 08:13
  • 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 – richzilla Feb 09 '17 at 08:14
  • 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? – Shaiju T Feb 09 '17 at 08:24
  • 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/` – richzilla Feb 09 '17 at 08:30
  • Yes you are correct but here its not a click, its about scrolling down in home page of the app , 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 ? – Shaiju T Feb 09 '17 at 08:38
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/53311/discussion-between-stom-and-richzilla). – Shaiju T Feb 09 '17 at 08:42