Add HTTP API for "live" commands about ditto HOT 4 CLOSED

Since live commands are implemented on devices the ditto SDK (Java AND JavaScript, capital 'and' since I fear the latter is a bit under-developed feature wise 😅) needs to provide as much guidance / abstraction as possible to ease the agent implementation. Some initial thoughts on this:

• if a command is not yet implemented for a feature on the live channel a 400 with an "unimplemented" notice should be returned. 400, because I don't know if there's any better suited status. 406 sound similar, but is semantically different.
• implementing the commands needs an API to 'plug-in' implementations
• for AMQP and MQTT connected clients I suppose (at least for mqtt) that the client will need an implementation to interact with an mqtt / amqp client ?

This might be worth another issue.

My basic idea here is to have as much of the API as possible defined as ditto protocol for commands, such that I don't need to worry much about status codes and such. Opposed to the messages API where implementation is highly use-case and device specific, which is good since e.g. (vorto) operations implemented as messages follow a custom API.

I'll additionally require a python SDK for some devices which I plan to open-source / contribute if we'll be the firsts to implement this ;)

from ditto.

This might be worth another issue.

I agree 👍
This issue is about providing the already existing "live command" concept via the HTTP API (only triggering "live commands", not answering them).

from ditto.

I've "discovered" an interesting use-case: I'm wanting to use the ditto commands API in "live" channel, but I'd also restrict users via policy from using the "twin" channel.

This is because I'd like the twin channel to only be accessible by the machine, while the user always uses the live-channel to alter things directly. This is to ensure that data is always going through the machine and is eventually dropped if the machine is not available. This is opposed to the desired-state pattern where I place desired state information for a device to retrieve. This is meant for situations where commands expire really fast and you don't want the machine to do anything if it's currently not accessible so you don't end up altering a state in a context you don't understand / know about.

To differentiate this from messages: to reduce the complexity of the used API I'd like to use live-commands instead of messages, because I really just need to set simple configuration values which seems a bit of overkill to use the messages API for.

What do you think?

(Also this might be worth another issue, feel free to hit me in gitter if this is too off-topic)

from ditto.

@w4tsn this is something which the current policy concept explicitly don't distinguish - the twin/live channel can't be separated from each other in a policy.
For the vast majorityof use cases we saw (and still see), this is also the expected behavior: if a user may interact with a device via live commands, he should also be able to "fall back" to the persisted twin state if e.g. the device is currently not offline.

I also fear that this would make (the already quite complex) policies even more complex.
So to be honest: I have my doubts that this would be desirable for the Ditto project to provide.

from ditto.