I’m working an API which works as “intermediary” between a REST API and the developer.
In this way, when the programmer do something like this:
User user = client.getUser(nickname);
it will execute a network request to download from the service the data about the user and then the programmer can use the data by doing things like
user.getLocation();
user.getDisplayName();
and so on.
Now there are some methods like getFollowers() which execute another network request and i could do it in two ways:
-
Download all the data in the
getUsermethod (and not only the most important) but in this way the request time could be very long since it should execute the request to various urls -
Download the data when the user calls the method, it looks like the best way and to improve it i could cache the result so the next call to
getFollowersreturns immediately with the data already download instead of execute again the request.
What is the best way? And i should let methods like getUser and getFollowers stop the code execution until the data is ready or i should implement a callback so when the data is ready the callback gets fired? (this looks like Javascript)
7
It is more convenient for you if you grab all the relevant data (about the user, the followers, etc.) in just one routine. You don’t have to worry about the partitioning of the access among several calls, or having some information available and some not, etc.
But having one big, honking call that takes a (possibly) long time to execute, and consumes a lot of both local and remote server resources to boot–that is a low scalability, anti-social design. I’m not saying never, ever do that–but it’s a lot more appropriate in exploratory prototypes than production code.
If you wish your User object to mask interactions with the REST API, then your getFollowers method should invoke the required behind-the-scenes shuffle to grab the followers information, then cache it locally. That is completely appropriate and typical. While the first request will take much longer than subsequent requests, c’est la vie.
Unless you are in a highly performance-constrained or latency-sensitive situation, it is unlikely that you want to involve asynchronous request/return mechanisms. They are complicated to get right, and notably complicate both your logic and that of User consumers.
You see async calls often in JavaScript–along with an army of callback handlers, registered event handlers, promises, futures, and other rendezvous techniques. That’s because JS has no other good mechanisms for handling threading/concurrency, and async has become the language idiom. You can do async calls in Java, for example with Futures. But by and large, Java programs tend to favor threads over async calls, and Java API consumers predominantly expect synchronous methods. Unless you have a specific requirement to do things async, or believe doing so will yield a substantial performance/latency win, don’t. Don’t do things that require your consumers to adopt an unexpected model of concurrency.
Note also that many REST APIs are paged. Requests like “get followers” or “get posts” return the first 20, 50, or whatever. Getting the next N objects requires a subsequent call. In those cases, making network / REST APIs calls is something that your getter methods might have to do across the life of your User objects, not just once or twice “up front.”
5
To me the best solution seems to be a method that takes an optional parameter that allows the caller to determine whether or not to include the follower data. In this way the caller can determine if it is appropriate to include the follower data in the call.
In a worst case scenario you have a few extra lines of code that never matter because the call always wants all of the data. However if the caller does not need all of that data and the application sees some performance hits from the collection of the extra data then some fine tuning can be done to allow for the conditional loading of the follower data.
On the other hand if you hard code it to always get the follower data then if it does become a performance issue the change will be more work if you have to make the change to allow for it at the call, or to make a separate call that only gets the user information. Implementing the optional parameter now should be a trivial task, and allow for the best fine tuning of the application with out having to modify your API.
7