#22 Data structure rework

[DanDayne]

References issue #22

The proposed structure of data returned by the get data endpoint:

{
"success" : <boolean>,
"cause" : <null OR string (exception detail etc.)>,
"data" : {
   <string (Log ID of the entry)> : {
      'command_id': '12',    ### SHOULD BE AN INT OR A STRING?
      'device_id': '1',            ### INT OR STRING?
      'is_valid': 1, 
      'response': {'pwm_pulse': 1, 'pwm_min': 0, 'pwm_max': 100, 'pwm_on': True},        ### DICT OR STRING?
      'source': 'D1-measureall', 
      'target': '[]',        ### LIST OR STRING?
      'time_executed': '2020-05-15 00:51:26',
      'time_issued': '2020-05-15 00:51:26'
      }
   }
}

Please, note the dict/list/string/int questions. @xtrojak, what is the expected (preferred) approach? Currently, each field tries to eval itself => dicts, lists and integers are returned instead of strings where possible. The downside of this is that if one of the other fields (command_id, device_id) MIGHT be pythonically evaluated into integers from strings, which might not be expected behaviour.

[xtrojak]

Generally IDs might be strings, so the issue you mentioned could cause some problems. However, we could force all IDs to be strings my adding a prefix (e.g. cmd for command and dvc for device), but I'm not sure if it is necessary.

I think lists/dicts are always preferred to strings.

[DanDayne]

rename field 'target' to 'arguments'

[xtrojak]

Final structure and value types.

{
"success" : <bool>,
"cause" : <not given OR str (exception detail etc.)>,
"data" : {
      'command_id': <str>,
      'device_id': <str>,
      'is_valid': <bool>, 
      'response': <dict>,   # e.g. {'pwm_pulse': 1, 'pwm_min': 0, 'pwm_max': 100, 'pwm_on': True},
      'source': <str>,        # e.g. 'D1-measureall', 
      'arguments': <list>,
      'time_executed': <datetime>,   # e.g.  '2020-05-15 00:51:26',
      'time_issued': <datetime>, 
      }
}

[DanDayne]

Since the successand cause fields only make sense when DeviceControl runs as a server, they will be omitted in the client approach. The aforementioned structure remains the same for server application, but as a client, the data structure sent should be as follows:

{
      'command_id': <str>,
      'device_id': <str>,
      'is_valid': <bool>, 
      'response': <dict>,   # e.g. {'pwm_pulse': 1, 'pwm_min': 0, 'pwm_max': 100, 'pwm_on': True},
      'source': <str>,        # e.g. 'D1-measureall', 
      'arguments': <list>,
      'time_executed': <datetime>,   # e.g.  '2020-05-15 00:51:26',
      'time_issued': <datetime>
 }

I do not see any reason to include any other information. Any additional thoughts, @xtrojak ?