19670Re: [rest-discuss] RESTful Toggle
- Jul 9, 2014Hi Robby,
If there are only two states, I would name the resource /binary, and
each time it receive a POST with a 1 bit in the body and responds with
a current tail bit. Internally, it just adds the 1 bit to the atomic
binary. I think it is RESTful.
On Wed, Jul 9, 2014 at 11:14 AM, Simpson, Robby (GE Energy Management)
> Hi Dong,
> Yes, in my application I'm actually more interested in a "blind" toggle like the pull handle of a slot machine. (Perhaps that would be a better example going forward)
> Regarding the POST, I'm still a bit confused as to how this would be constructed. In my applications, I've tended to use the POST method on "collection" resources to create a new resource that is a member of the collection. It seems to me if one had a resource /pullHandle and simply used POST with an empty body, that we are really heading down the RPC route rather than being RESTful. This also overloads the semantics of POST ("POST as create a member" and "POST as ?activate?"). Am I just overthinking here?
> From: "Dong Liu edongliu@...<mailto:edongliu@...> [rest-discuss]" <email@example.com<mailto:firstname.lastname@example.org>>
> Reply-To: Dong Liu <edongliu@...<mailto:edongliu@...>>
> Date: Wednesday, July 9, 2014 at 10:59 AM
> To: Erik Wilde <dret@...<mailto:dret@...>>
> Cc: Rest List <email@example.com<mailto:firstname.lastname@example.org>>
> Subject: Re: [rest-discuss] RESTful Toggle
> Hi Erik,
> I think when a use toggles, s/he must do that based on what s/he sees
> or in fact saw. If it is a "blind" toggle then it is like the pull
> handle of a slot machine. And I agree with you and Mike for a POST in
> that case.
> On Wed, Jul 9, 2014 at 10:52 AM, Erik Wilde <dret@...<mailto:dret@...>> wrote:
>> hello dong.
>> On 2014-07-09, 16:46 , Dong Liu wrote:
>>> I assume it is like a push button with no up/down or in/out lock.
>> exactly. and as such, the button itself does not have a state. you can
>> activate it, and it will toggle stuff. it probably would make a lot of sense
>> to make that activation non-idempotent, and i think mike has pointed that
>> out already.
>>> Anytime you push it and release, the state switches to the opposite of
>>> what you see. Robby was concerned about " 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?)"
>> i don't think PUT is a good model for a toggle service, as there's no state
>> to PUT. toggle inherently has race conditions, and if you don't like them,
>> then maybe toggle is not a service you should provide. just provide the
>> usual GET/PUT on the resource itself, and get rid of the toggle resource.
>> erik wilde | mailto:dret@... - tel:+1-510-2061079 |
>> | UC Berkeley - School of Information (ISchool) |
>> | http://dret.net/netdret http://twitter.com/dret |
- << Previous post in topic Next post in topic >>