19689Re: [rest-discuss] RESTful Toggle
- Jul 9, 2014(willh@...)Regards,In the end, the system should control the light directly, and should have access to the state of the lights. The "switches" (whether on the wall or an iPhone) should be inputs to the system, which then interprets those inputs and reacts with lights turning on and off. The switch does not turn the light on, it asks the system to turn the light on, and the system will do so if it deems it appropriate based on its internal rules.There are certainly scenarios for optimistic locking, I just don't really think this is one of them.From a user perspective, they want the light "ON", how that is achieved they simply don't care about.A conditional PUT is focusing on the mechanic, not the result.A PUT /light "ON" is idempotent. When it's done, the light is turned on, whether it was on or not.
The conditional PUT is "toggle the switch unless it's already toggled", which is pretty silly. It's silly because that level of coordination simply should not be exposed. It's also silly because it can be simply emulated by fetching the state and PUTing to the the Other State (or an other state).
As far as the latency issue, again, you're talking about primitives. If you need to control a bank of lights, create a representation at the appropriate granularity. Something like, I dunno, "room". PUT /lights/room/living ON.
Will HartungOn Wed, Jul 9, 2014 at 12:29 PM, Dong Liu <edongliu@...> wrote:Right, a conditional PUT does not match an N-way switch well. To me, it is even better than the real N-way switch because it reflects the true will of a user and avoids confusion (somehow magic) when his kids are pushing the other switches for the same light.On Wed, Jul 9, 2014 at 3:16 PM, Tim Bray <tbray@...> wrote:How is that idempotent? You absolutely can’t use PUT unless it’s idempotent.For a three-way or N-way switch, I prefer a conditional PUT to a POST.Cheers,DongOn Wed, Jul 9, 2014 at 2:45 PM, Will Hartung willh@... [rest-discuss] <firstname.lastname@example.org> wrote:But a "toggle" POST is just that, a simple command.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.So, with that consideration, a simple POST will do the trick.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.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.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".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.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.On Wed, Jul 9, 2014 at 9:36 AM, Erik Wilde dret@... [rest-discuss] <email@example.com> wrote:
On 2014-07-09, 17:47 , 'Simpson, Robby (GE Energy Management)'robby.simpson@... [rest-discuss] wrote:the problem is not that POST can mean anything (it can), but people
>> 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
> /command, where one could POST all sorts of commands like "toggle."
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).then how would a race condition enter the picture? just because of the
>> 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.
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...--- Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)
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.
- << Previous post in topic Next post in topic >>