I am trying to create a device management system for over-the-air updates. The system basically has 3 parts:

  1. Mobile client devices running android located at different places
  2. REST Backend written in Java using Jersey Framework running on Google App Engine.
  3. Web front end running on the browser of the users.

The use-case/flow is:

  1. 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.
  2. The REST Backend stores the details of the devices in a database(in this case google datastore)
  3. The web interface can be used by the user to view details of the devices and perform operations on it.
  4. 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:

  1. These additional parameters like city, country which are not sent by the device should also be shown.
  2. 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:

  1. The web client makes a REST API call to get all the devices
  2. Then it takes the list of deviceIDs from the response and makes a API call to the other service to get the additional details.
  3. 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?


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:

  1. 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.

  2. 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 for example to get all the devices in London, then the REST Backend first gets all the devices from the database, then calls external APIs with the list of all device IDs to get the details, then filters the response where city is London and then provides the response 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?

  • Is there a particular reason why the REST backend itself can't retrieve that information from the external APIs when needed? – Bart van Ingen Schenau Jul 21 '17 at 6:40
  • @BartvanIngenSchenau I have added some details regarding retrieving the details from REST Backend itself and why I think it may not be correct. Please let me know if my understanding/assumptions are wrong/incomplete – Archit Sinha Jul 21 '17 at 8:54
  • 1
    Bart is right. If you make your device app a mashup, you will have to face all the integration issues in the worse place. The client side. Usually, this is the main reason to make your backend the only and the unique data authority. While you can update and deploy your backend anytime, you have no control over the devices, so you will have to make changes backwards compatible with multiple versions of the client side app. Use your REST backend as a facade to decouple the client from all these implementation details. Make the client as agnostic to them as possible. – Laiv Jul 21 '17 at 9:13
  • The devices send periodic heartbeats to the REST Backend, in response to which it can send commands if any operations were requested by the user. Make sure you can scale out and up your backend. This sort of strategies have all the recipes for the disaster. (overall when implemented over HTTP). You have to be very careful with the concurrency and its pikes and size the backend accordingly with these factors. – Laiv Jul 21 '17 at 9:17
  • @Laiv , thanks for the response. I agree that this processing should not done at the web client as I had mentioned in my post earlier. Your comments also answers in a way answers the question in the first point in my EDIT to the question. However as I asked in the second point in my EDIT, I am not sure how it works in this case. Can you please provides some pointers/links/answers to the questions in point 2 of my EDIT. – Archit Sinha Jul 21 '17 at 10:31

Your Answer

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

Browse other questions tagged or ask your own question.