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

19693Re: [rest-discuss] RESTful Toggle

Expand Messages
  • Jonathan Ballard
    Jul 10, 2014
      "Is it ReSTul?"

      If I started with an override for the new OPTION:QUEUE and demonstrate it, I know, some people will consider it incomplete. If stateless means someone else finishes it and gets credit for it, the toggle is bad or not ReSTful.

      We have an ugly toggle, and that is the existentialism of /#.

      POST /#/start
      POST /#/stop
      DELETE /#

      On Wed, Jul 9, 2014 at 10:06 PM, Jørn Wildt <jw@...> wrote:
      [Sorry for being a bit late to this party.]

      Is it RESTful? Thats a question we see a lot of times ... "Is this POST to /xyz RESTful" or "Is this a RESTful URL" or "Is it RESTful to DELETE this?". Thats not easily answered and its very much like taking a brick, a flooring tile or a piece of wall paint from a specific church building and ask "Is this brick/tile/paint Grotesque?". But a brick in itself doesn't necessarily adhere to any specific architectural style - it can be used in many different styles. And the same goes for a URL/HTTP VERB/media-type what ever - you cannot say in isolation whether it is RESTful or not - it depends on how the overall building/system is built/implemented.


      On Wed, Jul 9, 2014 at 11:50 PM, Jonathan Ballard dzonatas@... [rest-discuss] <rest-discuss-noreply@yahoogroups.com> wrote:

      An upgrade to that would be to override with new OPTION:BANK for an array of those kind of toggles.

      [This forward-looking statement is intentional.]

      On Wed, Jul 9, 2014 at 2:44 PM, Jonathan Ballard <dzonatas@...> wrote:
      It may require another resource. Move/Swap/Redirect the two states (on and off) based on current state rather than one specific state that has no mechanism itself for toggle. It depends on how persistent and concurrent you want the two states.


      POST /state/on
      POST /state/off
      PUT /state/toggle
      DELETE /state

      Returns semantics for redirected or moved resources. Override with new OPTION:TOGGLE. 

      On Wed, Jul 9, 2014 at 6:06 AM, Keith P Hassen keith.hassen@... [rest-discuss] <rest-discuss-noreply@yahoogroups.com> wrote:

      You could implement a POST operation that simply flips the state, whatever it is.  If you implement PUT, the request should be idempotent but it's unclear if that's what you intend here.  Protecting against the kind of race conditions you mention is usually performed with conditional requests (If-Match, If-None-Match, etc).


      On Tue, Jul 8, 2014 at 5:28 PM, 'Simpson, Robby (GE Energy Management)' robby.simpson@... [rest-discuss] <rest-discuss-noreply@yahoogroups.com> wrote:


      I've been scratching my head over this one for a while and am hoping I can
      get some help.

      Imagine a light switch with one simple resource: /state , where state can
      be "On" or "Off."

      One can PUT to /state , changing /state to either "On" or "Off."
      Similarly, a GET to /state will tell you if the light is currently "On" or

      Where I'm struggling is with a safe "Toggle" mechanism. That is, if
      /state is "On", change it to "Off" and vice versa.

      I understand that one solution would be to simply perform a GET on /state
      and then PUT the opposite. However, I am concerned with both the overhead
      and latency this entails as well as the potential for a race condition
      (what if /state changes between the GET and the PUT?).

      Any solution I've looked at thus far seems to violate RESTful principles,
      particularly regarding idempotency. In short, can one safely toggle?

      Any suggestions?


    • Show all 36 messages in this topic