Duplicated "deviceGuid" key on Command GET /device/command/poll

[edubovik]

#136 Duplicated "deviceguid"

{
    "command": 
    {
      "id": 947936808,
      "command": "onewire/dht/read",
      "timestamp": "2015-11-15T20:47:21.534",
      "userId": 10,
      "deviceGuid": "esp-device-581688cb236c0ef4",
      "parameters": {
        "pin": 1
      },
      "lifetime": null,
      "status": null,
      "result": null
    },
    "deviceGuid": "esp-device-581688cb236c0ef4"
  }

[zubrabubra]

@edubovik @demon-xxi @YermakovSergiy @Pilatuz @Nikolay-Kha @vyrostkov @vktk

API change request for poll/pollMany.

Implemented by .net server existing protocol

pollMany: [ {guid, commandT1}, {guid, commandT1}, ... ]
poll: [{commandT1}, {commandT1}, ...]

where commandT1 object does not contain device guid, while option is to change conversation response to

pollMany: [ {commandT2}, {commandT2}, ... ]
poll: [{commandT2}, {commandT2}, ...]

where commandT2 object does contain device guid.

Java server provides:

pollMany: [ {guid, commandT2}, {guid, commandT2}, ... ]
poll: [{commandT2}, {commandT2}, ...]

Feel free to provide your responses.

[demon-xxi]

I think it is important to maintain same contract for the Command entity regardless of the method called (poll or pollMany). That will minimize complexity on the client side too. So including device guid in the command is the way to go and we can skip it in results. That will affect .net compatibility but not a big migration change to do.
For better compatibility we can also use protocol versioning in .net and/or java as well. Not sure if we havr time to do so now.

[edubovik]

I am completely agree with Sergey. It is important to have same schemes for both methods.

[Nikolay-Kha]

+1 for the same schemes for both methods.

[zubrabubra]

Changing the API to follow simplified model:

pollMany: [ {commandT2}, {commandT2}, ... ]
poll: [{commandT2}, {commandT2}, ...]

where commandT2 is object instance with device guid in it.