> i often model resources as state machines and include event & state params.

> PATCH /invitations/{id}?event=accept
> Accept it (using PATCH to be fancy)

> GET /invitations/{id}
> Read the invite. It will have attribute 'state' with value 'accepted'

> when i build stuff with Rails, i use the state_machine gem with most of my
> models to support this behavior:https://github.com/pluginaweek/state_machine

> -b

> On Tuesday, April 10, 2012 8:24:06 PM UTC-4, Greg Brail wrote:

> > What about the "action" pattern that I've seen on a few APIs, combined
> > with POST, like this:

> > GET /invitations/{id} : Read the invite
> > POST /invitations/{id}?action=accept : Accept it
> > POST /invitations/{id}?action=decline : Decline it
> > DELETE /invitations/{id} : Rescind the invitation (only authorized for the
> > organizer)
> > PUT /invitations/{id} : Update it (add a dial-in number, directions, etc).

> > With this pattern, "/invitations/{id}" unambiguously refers to a single
> > invite, which you can manipulate using the standard verbs or not as you
> > extend your API. The POST with the "action" parameter is essentially a
> > partial update of the invite, with semantics that depend on the action.
> > (Yes, it's like a method call, so shoot me ;-)

> > You could also use PATCH for that if you wanted to be fancy.

> > On Tue, Apr 10, 2012 at 3:47 PM, Richard Berger <richardlan...@gmail.com>wrote:

> >> Thank you to everyone for taking the time to provide some guidance.  I
> >> am now much more comfortable going with a "PUT" with a URL something
> >> like /invitations/<id>/accept, /invitations/<id>/decline, etc.  (Mike
> >> S - I would consider putting the actName inside the body, but that
> >> would require a bit more learning on my part).

> >> Also the suggestion of If-Match header to make sure that the act is
> >> still valid is very helpful (but sadly, requires yet more learning).
> >> I am planning to add OAuth for user verification - but that is in the
> >> future.

> >> Again, thanks to all, I am set for now.
> >> RB

> >> On Apr 10, 2:51 pm, Daniel Roop <dan...@danielroop.com> wrote:
> >> > I think it is ok for link "rel"s to be verbs "approve", "decline" etc...

> >> > I think some people are starting to accept that some verbs in URLs are
> >> ok.
> >> >  The trend I have seen is calling them Controller Resources, or Action
> >> > Resources.  Both REST In Practice and the REST API Design Rule Book talk
> >> > about them if I remember correctly.

> >> > I tend to think about verbs as a bad smell and a habit that needs to be
> >> > broken, but once you have broken it and understand the difference
> >> between a
> >> > resource and a method some uses are appropriate.

> >> > The other way to tackle this is to provide a collection that represents
> >> the
> >> > actions you want to do....

> >> > For instance imagine you had an invitation that could be approved or
> >> > declined.

> >> > You could have

> >> > /invitations/<id>
> >> > /invitations/<id>/accept
> >> > /invitations/<id>/decline

> >> > Or you could have

> >> > /invitations/<id>/
> >> > /accepted-invitations/
> >> > /declined-invitations/

> >> > Where to the bottom two collections you post the URL or ID of the
> >> > invitation to perform the state transition.  The way I rationalize
> >> this, is
> >> > imaging you are filling out a form with the acceptance, and that
> >> collection
> >> > keeps track of those forms for you.

> >> > Another thing to consider is that if you are using links, either one of
> >> > these should work, because your link relation should define the method
> >> that
> >> > should be used, as well as the content that should be sent.  If you are
> >> > using something WRML or at least the link "rel" resource it suggest the
> >> > client can discover atl east the method in the rel resource.

> >> > Daniel Roop

> >> > On Mon, Apr 9, 2012 at 5:43 PM, Mike Kelly <mikekelly...@gmail.com>
> >> wrote:
> >> > > You might also want to require an If-Match header to prevent
> >> > > conflicts, and possibly have the client explicitly specify the
> >> > > identity of the user that is agreeing to the supertask.

> >> > > Cheers,
> >> > > Mike

> >> > > On Mon, Apr 9, 2012 at 9:33 PM, Mike Schinkel <m...@newclarity.net>
> >> wrote:
> >> > > > On Apr 9, 2012, at 3:43 PM, Richard Berger wrote:

> >> > > > It seems that the standard solution to this is to update the state
> >> > > > through a Put.

> >> > > > BUT, in my case it seems that I wouldn't want the client developer
> >> to
> >> > > > know all the possible states of the finite state machine, but I
> >> think
> >> > > > the developer would be more comfortable dealing with the user
> >> actions
> >> > > > (agree to SuperTask, complete it, reject it, renegotiate, cancel).
> >> > > > This would lead to an api similar to /supertask/id/action=agree (the
> >> > > > evil verb approach :) ).

> >> > > > What about this?

> >> > > > PUT /supertask/id/status

> >> > > > <body>: agree

> > --
> > Gregory Brail  |  Technology  |  Apigee