You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Need example of PUT /things/<thing>/actions/<action>/<id> #84
changed the title [-]Need example of GET `/things/<thing>/actions/<action>/<id>`[/-][+]Need example of GET /things/<thing>/actions/<action>/<id>[/+]on Mar 28, 2018
changed the title [-]Need example of GET /things/<thing>/actions/<action>/<id>[/-][+]Need example of PUT /things/<thing>/actions/<action>/<id>[/+]on Mar 28, 2018
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
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.
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.
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?
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.
Activity
[-]Need example of GET `/things/<thing>/actions/<action>/<id>`[/-][+]Need example of GET /things/<thing>/actions/<action>/<id>[/+][-]Need example of GET /things/<thing>/actions/<action>/<id>[/-][+]Need example of PUT /things/<thing>/actions/<action>/<id>[/+]sogaani commentedon Apr 17, 2018
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 commentedon Apr 18, 2018
@sogaani "DELETE" here refers to an HTTP DELETE request in the REST API, not any UI implementation.
sogaani commentedon Apr 18, 2018
@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 commentedon Apr 19, 2018
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 commentedon Jul 22, 2019
Why not
/things/<thing>/<thing id>/actions/<action>/<id>or/things/<thing>/actions/<id>?dravenk commentedon Aug 20, 2019
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 commentedon Aug 20, 2019
Related: #66 (comment)
hobinjk commentedon Aug 20, 2019
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/2will happen after/actions/fade/1is completed. One could then design a light show withPOST /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.