Loading ...
Sorry, an error occurred while loading the content.

19687Re: [rest-discuss] RESTful Toggle

Expand Messages
  • Dong Liu
    Jul 9, 2014
      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.

      On Wed, Jul 9, 2014 at 12:09 PM, Dong Liu edongliu@... [rest-discuss] <rest-discuss-noreply@yahoogroups.com> wrote:

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



      On Wed, Jul 9, 2014 at 2:45 PM, Will Hartung willh@... [rest-discuss] <rest-discuss-noreply@yahoogroups.com> 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.


      Will Hartung

      On Wed, Jul 9, 2014 at 9:36 AM, Erik Wilde dret@... [rest-discuss] <rest-discuss-noreply@yahoogroups.com> wrote:

      hello robby.

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

      robby.simpson@... [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...



      erik wilde | mailto:dret@... - tel:+1-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.

      - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

    • Show all 36 messages in this topic