FLOIP / flow-results

Open specification for the exchange of "Results" data generated by mobile platforms using the "Flow" paradigm
6 stars 2 forks source link

Version control for API access #12

Closed markboots closed 6 years ago

markboots commented 6 years ago

The "retrieve" mode of the API allows accessing a flow package description, with a separate command to access the responses for that description.

This creates a potential problem if:

1) A client accesses the package descriptor 2) The package is modified to add new questions, or remove existing questions 3) A client accesses the results, assuming the same original questions

There are actually two problems:

To avoid these issues, this is a suggested version control system for versioning flow descriptors:

1) Descriptors already have a "modified" timestamp. This can be treated as a version control indicator for a package descriptor uuid. 2) Within versions (designated by a modified timestamp) of a package (designated by uuid), the only allowed modifications in more recent versions are to add additional questions. Implementations may not remove questions in more recent versions. 3) When accessing responses via the "Retrieve" API, a client may request a "version" filter, which should return only responses to versions of the flow up to that version specified. Note that this is different than specifying a latest timestamp filter for the responses, which could include responses more recent than the modification time of the flow... as long as these responses were recorded for a version of the flow of the specified timestamp or earlier.

ggiraldez commented 6 years ago

I'm not sure I fully understand the implications of this. Can you elaborate with a couple of examples?

My initial reaction would be to try to keep the descriptor-responses relations as immutable and stable as possible. As such, I wouldn't allow returning responses for "incompatible" descriptors.

Thus, to allow modifications to the flow I see two possible alternatives:

1) adapt all the recorded responses structure to the latest descriptor, which may involve adding null-valued responses or removing other responses 2) keep descriptors immutable and create new instances of them whenever modifications are made, maybe linking together the different versions and their corresponding response batches; of course, it's not necessary to keep all descriptor versions, only those that have associated responses.

markboots commented 6 years ago

Discussed on the call: could add a "vendor_info" field to packages to store whatever additional identification a vendor wants.

markboots commented 6 years ago

Closed via https://github.com/FLOIP/flow-results/pull/17