Returning large amount of data from server to be used on different screens on mobile phone RRS feed

  • Question

  • User-529154869 posted

    I am working on an api that needs to support a mobile phone application, and I am working with existing code that feeds data to the api's that cant be modified.  Also the phone application is supposed to be a true dumb client, all business logic is processed on the server.

    On the mobile phone it has a series of screens consuming the same set of data.  And what to display on the phone depends of values of different fields and what are selected on each screen on the phone.  Between screens based on what values are selected, the data that was sent from the api is updated by the phone and sent back to the server for processing without saving to the database, until the last screen where user hits Save.  Then the server will send back the processed data to the phone for next screen.

    Since the api's are supposed to be stateless and no data is being stored in the database until the last screen, I have to pass large amount of data between server and the phone for each response and request.  So given the constraint that the underlying services below the api layer cannot be modified or added to, my question is, is the only option to pass this huge data back and forth?

    Any insight is greatly appreciated.

    Friday, April 14, 2017 11:03 PM

All replies

  • User475983607 posted

    Store the information in a database and pass a key to the data between the mobile app and API.
    Saturday, April 15, 2017 2:08 PM
  • User-529154869 posted

    Thanks for the response.  The requirement is to use existing services and I wont be able to add new services for database operations.  The existing call to update the database expects all fields updated before writing and that will have to happen at the very last screen when we have collected all the updated data.  So what you suggested wont be possible in my scenario.

    But I am curious though, what is the purpose of this key?  To identify the correct caller?

    Saturday, April 15, 2017 9:22 PM
  • User475983607 posted
    Confused... it seems you knew all along that the client needs to persist that data due to a requiment.

    As for the key, it is a unique identifier used to retrieve the persisted data. It could be a userId, a guid, or a combination of data elements.
    Saturday, April 15, 2017 10:05 PM
  • User-529154869 posted

    Sorry if it was confusing....

    The truth is, yes we can do this, we can have the data persisted on the client side and send it back to server, multiple times.  The question is whether there is a better way.  I guess the question can also be, is it such a bad idea to send this large amount of data to and from client and server every time.

    Tuesday, April 18, 2017 11:24 PM