benfrancis
commented
5 years ago The queue is intended to represent the fact that not all actions happen synchronously. A client can request an action and then either listen for an actionStatus message via the WebSocket API or query its state via the REST API.
If a device implements an action synchronously then it can just immediately send an actionStatus message and set the action request resource to the completed state.
So yes, I'd suggest things should implement an action queue as that's what clients will expect. But note that in many cases if an action takes place immediately it can often be represented as a property change rather than an action. From the spec:
Actions are used when the setting of a property alone is not sufficient to affect a required change in state. This may be used to describe a function which takes a period of time to complete, manipulates multiple properties, or has a different outcome based on provided arguments or current state.
The current draft of the spec doesn't formally define things like SHOULD or MUST, we will eventually make it more formal once things settle.
Simple Things probably tend to run their actuators synchronously from the incoming action. Section 3.4 Actions talks about a queue, but nowhere in the document can I find whether there is a requirement for all Things to have such a queue, and just what exactly it would do.