I am trying to create a device management system for over-the-air updates. The system basically has 3 parts:Mobile client devices running android located at different placesREST Backend written in Java using Jersey Framework running on Google App Engine. Web front end running on the browser of the users.The use-case/flow is:Each mobile client has some information about itself including a unique device ID. The client is also programmed with credentials to enable to access the REST API to create, update itself.The REST Backend stores the details of the devices in a database(in this case google datastore)The web interface can be used by the user to view details of the devices and perform operations on it.The devices send periodic heartbeats to the REST Backend, in response to which it can send commands if any operations was requested by the user.Now the problem is that, there are certain details regarding the device, lets say for example the city, country where it is located is not available with the device.It is available with some other service which has APIs which takes the device ID (or a list of device IDs) and returns the details corresponding to it.When the user want to see the list of devices:These additional parameters like city, country which are not sent by the device should also be shown.It should also be able to filter/group devices and perform operations on them. For example, user may want to perform operation X on all devices in London.So my questions is basically where and how is the best place to get the details.I had initially thought that it can be done at the web client, meaning if the users wanted to see all device in city C:The web client makes a REST API call to get all the devicesThen it takes the list of deviceIDs from the response and makes a API call to the other service to get the additional details.It filters the response(with some javascript code) where the city is C and then shows it to the User.However, I think that this approach is not correct since it involves quite a lot of processing at the client browser. Also if the number of devices increase, it will lead to issues.So does there need to be something in between the web client and the REST backend which actually makes the REST APIs calls and does all the filtering and then provides the result to the client browser? If yes, then where should it sit and what types of APIs/interaction should it have with the client?What is the best way to handle this?EDIT:Regarding having the REST backend itself retrieve the details from the external APIs, It can be done, but I thought it may not be appropriate due to the following reasons:Later I may want to use this system for a different deployment(different set of devices), in that case, the external APIs, credentials to access them and the response fields would change. So, I thought it would be better not to have these set in the REST backend to keep it generic.I haven't worked much with RESTful services or web services in general, I am not clear how/what would the flow be in case the REST backend is itself doing the fetching:   a. Meaning is it like whenever the client browser sends a request forexample to get all the devices in London, then the REST Backendfirst gets all the devices from the database, then calls externalAPIs with the list of all device IDs to get the details, thenfilters the response where city is London and then provides theresponse to the web client.b. If this is the case then should the external API call from the REST Backend be synchrnous or aysnchronous. If it is synchronous, then the response time for the web client to the request it sent will be high. Google App Engine I think has a time-limit of 60 seconds for HTTP requests.c. If the calls to external APIs are asynchronous, then what does the REST Backend return to the web client when it makes the GET request.d. Also, in this case, the REST Backend would in a way be acting both as a REST Server and a Client. Is that correct? I mean in whatever tutorials/examples I saw I didn't see any such usage? 
Developing mobile device management system
rest;web services;google app engine