I am in process of building Mash up mobile application. I need to call my API Provider and integrate with Facebook , twitter etc. During this process, I have to make multiple REST API calls one after other to same domain(with different path and query parameters ofcourse). Also the API calls has to be sequential as in result of one is required to call the next. What are the ways I can optimize these http calls to avoid the round trip. Suggestions for java and js is welcome
The requirements stated are broad. Since you are using the public third party API, that somewhat limits the scope of possible optimizations. There is absolutely nothing that you can do to speed up the APIs as they do not belong to you.
In general I suggest following guidelines which will help you come up with better application.
On the side note, you can refer to following links which offer general guidelines for developing a mobile App.
Please note that these are general guidelines. Some may not apply to your particular use case.
If you need the results of the first API call in order to make the next API call, then there is nothing you can do client-side to avoid a sequential round-trip for each one. There would either need to be an existing API call that can be used to combine multiple calls into one or you would need to add such an API call to the server or you would need to use a proxy server that does that on your behalf.
If you don't need the results of the first API call in order to make the next API call, but you just want to process the results in sequential order, then you can make all the API calls at once and structure your response code to process them in order (saving any results that arrive out of order for later processing).
Programming level - use code optimization/threading/parallel programming.
API level - use pagination/filters/ranges to generate fine-grained data that is tailored to the need of the client.
Cache - Have heard somewhere that the "fastest HTTP call is the one that you don't make" that is, use caching(Memcache/Redis), most of the requests are read operations, wise use of cache control headers are also useful. That spares the database from serving repeated read requests which are expensive. (Not sure if Etags can be of any use ?)
Request/Response - Use JSON serializer and gZip compress techniques for the data transmitted over the web.
Geography - Account for the distance between end users and origin servers, we can use CDNs for storing the static contents of the response, so that it can be served real fast.
(Have heard about asynchronous methods/reactive programming which improves the performance of APIs, but not so sure)
REST is unified and therefore, filters and round trips are necessary to accomplish a certain functionality. When it comes to optimization and imitating multiple clients request into ONE, you will slowly start facing challenges of a unified paradigm since it client can be a lot more specific than the contract can do in ONE UNIFIED call. While REST can be heavily optimized to drop the number of API calls to two or even one call, sometimes, your client request will require complex filtering that will require a feedback from the server prior to applying additional filtering logic.
If your requirements that you absolutely have to have ONE API call to handle specific client request from the server instead of the client while all filters is not applicable, then RPC will be your way to go, which will take care of specific business logic in a restful manner from the server to other micro-services (SOA.)
The real question is why you would have the server to handle such request if you want to keep your REST API unified and consistent and have the clients implement their own unique logic. The REST API server should provide the client with hyperlinks/hypermedia to guide the client of best way to reduce the number of API calls whether by filtering or any other entity/resource.
If you could use jQuery, I suggest you have a look my plugin jQuery Chain which could help make async call sequential.
©2020 All rights reserved.