13

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?

12

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

  • 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 ? – stom Feb 9 '17 at 9: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 9 '17 at 9: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 ? – stom Feb 9 '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 9 '17 at 10:31
  • 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. – stom Feb 9 '17 at 10:51
4

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.

  • Thanks, so you mean single url for API but request should to different resources be made using Query String ? , also check this. – stom Feb 9 '17 at 8: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 9 '17 at 8: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 9 '17 at 8: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? – stom Feb 9 '17 at 8: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/<tagname> – richzilla Feb 9 '17 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.