Re: RESTful Toggle

From a design perspective, I prefer a conditional PUT as well.

Unfortunately, latency is a major issue with wireless lighting (i.e., users do not want to notice any delay) and there is a perception that having to have a GET before a PUT would introduce too much latency.  Especially in scenarios where there are multiple lights (multicast).

- Robby

From: "Dong Liu [email protected]<mailto:[email protected]> [rest-discuss]" <[email protected]<mailto:[email protected]>>
Reply-To: Dong Liu <[email protected]<mailto:[email protected]>>
Date: Wednesday, July 9, 2014 at 3:09 PM
To: Will Hartung <[email protected]<mailto:[email protected]>>
Cc: Rest List <[email protected]<mailto:[email protected]>>
Subject: Re: [rest-discuss] RESTful Toggle



For a three-way or N-way switch, I prefer a conditional PUT to a POST.

Cheers,

Dong


On Wed, Jul 9, 2014 at 2:45 PM, Will Hartung [email protected]<mailto:[email protected]> [rest-discuss] <[email protected]<mailto:[email protected]>> wrote:


From home automation point of view, I can only think of one use case where "toggle" actually has any validity, and that would be in the "3 way switch" scenario.

A 3 way switch is exemplified by walking up to a dark hallway, turning the light on with a nearby swtich, walking to the end, and then turning the light off with a switch at the other end.

This use case is a true "toggle", since the "state" is the actual light (on or off), and the switch itself does not represent that state (unlike a normal, single switch). The switches can be "up" or "down" unrelated to the light being "on" or "off".

Given that, again from a home automation point of view, I can't really ever see "toggle" as a viable action. Maybe it's a primitive. But, in the end, when you walk in to that dark hallway, what you want is the light to go on, the mechanics of the switches are secondary.

I just mention this because at a high level, "toggle" doesn't make much sense to me. The automation folks may well need it as a primitive to control a switch. But at the "application" level, it doesn't make much sense. At an application level, you either want the "Light" ON or OFF.

So, with that consideration, a simple POST will do the trick.

I don't think there's any "race condition", because "toggle" is not a state, it's an action. If you care about the state, then set the state you want. You should hide the "toggle", and enforce the state behind the scenes (where you can manage race conditions on the server). Let the server decide that when you change the state to ON, it can determine, internally, if the device is OFF and then send a TOGGLE command to make it ON. If it's already ON, then nothing happens.

But a "toggle" POST is just that, a simple command.

Regards,

Will Hartung
([email protected]<mailto:[email protected]>)




On Wed, Jul 9, 2014 at 9:36 AM, Erik Wilde [email protected]<mailto:[email protected]> [rest-discuss] <[email protected]<mailto:[email protected]>> wrote:


hello robby.

On 2014-07-09, 17:47 , 'Simpson, Robby (GE Energy Management)'

[email protected]<mailto:[email protected]> [rest-discuss] wrote:
>> it sounds like the scenario we were talking about, that all you want is
>> to tell the resource to "reverse its state". in this case, i'd POST a
>> body that represents this request, in whatever serialization you happen
>> to prefer. the resource toggles. everybody's happy.
> OK. Still seems like a bit of a departure from typical RESTful interfaces
> I've seen and has the potential to be a catch-all tunnel for RPC-style
> requests.
> E.g.:
> /command, where one could POST all sorts of commands like "toggle."

the problem is not that POST can mean anything (it can), but people
POSTing things to a "do stuff" resource, which then isn't
resource-oriented anymore. your RPC sensor shouldn't go off because of
people POSTing things to resources (that's fine), but because of people
POSTing things to something other than resources (the "API end point",
for example).


>> but i am confused because you wrote earlier that you were concerned
>> about race conditions. which seems to imply that instead of just
>> toggling, you're also assuming that you're "toggling *from* some state".
>> but that wouldn't be the "blind toggle" we discussed. could you clarify
>> a bit how exactly the operation that you're trying to design is defined?
> Apologies, a blind toggle is what is desired. As it currently works, in
> the current binary protocol, a button press on a toggle switch simply
> sends a "toggle" command.

then how would a race condition enter the picture? just because of the
timestamp when you last observed the resource's state? or something
else? to me, toggling always is kind of a game: if somebody toggled
ahead of you, you'll do something other than you wanted to, but that's
how it is and you'll have to deal with it after toggling and finding out
that you switched the damn thing back on again...


cheers,

dret.

--
erik wilde | mailto:[email protected]<mailto:[email protected]> - tel:+1-510-2061079<tel:%2B1-510-2061079> |
| UC Berkeley - School of Information (ISchool) |
| http://dret.net/netdret http://twitter.com/dret |


CONFIDENTIALITY NOTICE: The information contained in this electronic transmission may be confidential. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by email reply and then erase it from your computer system.





------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/