Re: [TF-TD] Meeting minutes + Update TD Tutorial

Here is the way I understand the distinction:

A number of resources on a server can be operated on directly using REST
primitives such as GET and PUT.  These are modeled as properties.

However, sometimes the state changing actions on a resource are more
complicated.  E.g., brewing a cup of coffee cannot easily be modeled as
a PUT.  In particular, one might want to start a longer-running action
and then modify the course of the action (e.g., canceling it, or
changing some parameter) while the action is being implemented.

To model this in REST, starting an action that is more complicated than
a simple PUT needs to create a resource that then can be further
manipulated.  (I'm not sure about the terminology here; I'd prefer to
call each of these newly created resource an action, and use a different
name for the resource that is used to create such an action, e.g.,
operation; maybe there are better terms.)  Performing a POST on such an
operation resource creates an action resource that is then returned in
the Location options/header fields of the request.  The action may have
additional operations such as cancel (might simply be modeled as a
DELETE of the action, or may require additional steps if the
cancellation itself takes some time and needs to be monitored, in which
case one would use a POST again).

So, since ledOnOff is instantaneous (no need to watch the LED turning on
or off slowly), this can still be a simple property.  fadeIn, however,
might be started and then canceled, or a client might simply want to
watch the action as it is occurring (e.g., to mirror it in a UI).

Grüße, Carsten


kajimoto.kazuo@jp.panasonic.com wrote:
> For example, “ledOnOff” belongs to Property, on the other hand “fadeIn”
> and “fadeOut”
> 
> belong to Action.
> 
>  
> 
> “ledOnOff” will cause things=LED turn on or off. So “ledOnOff” can
> belong to Action
> 
> category too, I think.
>

Received on Sunday, 6 September 2015 11:58:28 UTC