Need example of PUT /things/<thing>/actions/<action>/<id>

[sogaani]

Considering The Gateway UI which control actions, If an user want to stop action, I feel that cancel button is better than delete button. The user can not see log of the action deleted.

[benfrancis]

@sogaani "DELETE" here refers to an HTTP DELETE request in the REST API, not any UI implementation.

[sogaani]

@benfrancis Oh sorry, my explanation was not enough. I am thinking canceling action is example of 'PUT' request. To stop an action with the current API, we must delete an action using 'DELETE'. In the REST API, 'DELETE' means deletion of a resource, so despite the action being executed halfway, the history of the action has disappeared.

In my case, I will implement an action which learn multiple (eg Light on / off) ir code in succession. If stopping the action in the middle, if some ir code is learned, the user will want to check what was learned and restart from the middle.

[benfrancis]

Oh I see what you mean. Yes there would be a benefit to using a PUT or PATCH to cancel the action request rather than a DELETE which would remove all record of the request.

[dravenk]

Why not /things/<thing>/<thing id>/actions/<action>/<id> or /things/<thing>/actions/<id> ?

[dravenk]

I think /actions/<action>/<id> very confusing. Like I have a Lamp, add a toggle action, and then I get /actions/toggle /<toggle id 1>. This also means I could have /actions/toggle /<toggle id 2>, right? It's like a Lamp with two toggle actions, instead of a toggle being updated twice.
For example, I make two temperature change Action requests to a thermometer that last 10 seconds, one for an increase of 10 and one for a decrease of 10. How does the temperature change over time? Shouldn't it be an Action and then update with PUT or PATCH?

[dravenk]

Related: https://github.com/mozilla-iot/wot/issues/66#issuecomment-373130889

[hobinjk]

Each /actions/toggle/<id> is a specific instance of the toggle action being requested.

At least in my understanding, actions of the same name are expected to form a queue so /actions/fade/2 will happen after /actions/fade/1 is completed. One could then design a light show with

POST /actions/fade {input: {color: "red", duration: 10000}} -> /actions/fade/1

POST /actions/fade {input: {color: "green", duration: 10000}} -> /actions/fade/2

POST /actions/fade {input: {color: "blue", duration: 10000}} -> /actions/fade/3

And then they could modify the action queue with things like the following:

PUT /actions/fade/2 {input: {color: "yellow"}} to change the middle color of the impromptu light show

PUT /actions/fade/2 {status: "canceled"} to cancel the middle action

In the temperature example I would expect it to change increase by 10 over the course of 10 seconds then decrease by 10 over the next 10.