Question

I have a mobile device that is constantly recording information. The information is stored on the device’s local database. Every few minutes, the device will upload the data to a server through a REST API – sometimes the uploaded data corresponds to dozens of records from the same table. Right now, the server responds with

{status: "SAVED"}

if the data is saved to the server.

In the interest of being 100% sure that the data is actually uploaded (so the device won’t attempt to upload it again), is that simple response enough? Or should I be hashing the incoming data and responding with it, or something similar? Perhaps I should send back the local row ids of the device’s table’s rows?

Answer 1

I think it’s fine to have a very simple “SUCCESS” response if the entire request did indeed successfully save.

However, I think that when there is a problem, your response needs to include the IDs (or some other unique identifier) of the records that failed to save so that they can be queued to be resent.

If the same records fail multiple times, you might need to log the error or display it so that further action can be taken.

A successful response could be something as simple as:

<response>
    <status>1</status>
</response>

An error response could be something like:

<response>
    <status>0</status>
    <errorRecords>
        <id>441</id>
        <id>8462</id>
        <id>12</id>
    </errorRecords>
</response>

You could get fancy and have different status codes that mean different, more specific messages.