Cleanest RESTful design for purely "action" calls?
Posted
by Josh Handel
on Stack Overflow
See other posts from Stack Overflow
or by Josh Handel
Published on 2010-03-04T20:07:39Z
Indexed on
2010/04/08
6:53 UTC
Read the original article
Hit count: 490
Hello all, I am sticking my toe in the RESTful waters and I just can't find a "satisfactory" solution to how to handle truely "action" oriented calls on a RESTful service? My quandry can be broken down into two parts.
1) Transactional calls: I understand the idea of having an ActionTransactor that you get a resource too with a post, update the parameters and then commit with a PUT (as described all over the place and in the Orilly RESTful Web services book).. But I struggle with the idea of keeping URLs with states present for ever.. If we really honestly don't need to keep a transaction for ever can we kill the resource URI? do URIs need to be perminate or can they be transiant URIs that expire
2) Non transactional calls: these might be calls to perform some workflow that spans multiple resources but having a resource just doesn't make since.. An example might be to re-generating some calculated ans cached value like a large aggreget or re-indexing blog or some such "purely" action.
Anyways, I'm curious about the communities thoughts on this... Thus far, I've read that Overloading Post is the cleanest way to handle part 2.. But there is an equal amount of argument against that approach as well. And (to me) its not self documenting which I though was one of the key design goals of RESTful APIs.
© Stack Overflow or respective owner