Cleanest RESTful design for purely "action" calls?

I am sticking my toe in the RESTful waters and I just can't find a "satisfactory" solution to how t开发者_如何转开发o 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.

1). Keeping URIs with states forever: Consider any web site. It has some pages. Some get removed and we get a 404 when we attempt to access them. Consider a database with, say, customers in it. Our RESTful accessor has URIs such as http://myserver/customer/12345 - if the customer has been zapped then we can return a 404. Seems quite reasonable to me. URIs are transient in that they may be syntactically valid but the system has well-defined behaviour if the resource is now stale. I believe that error handling for restful services is an important consideration. I discuss this here

2). Actions that don't seem to quite fit the REST model: I'm not sure whether PUT or POST is the most appropriate method. How about the idea that the resource is the request to do something? So we could PUT/POST to

http://myserver/request/cacheupdate

This can return a request payload including a unique id (just like creating a customer could return customer info including a system-generated id). The request resource can then be used to determine whether the request has completed, using the unique id.

http://myserver/request/12345

This allows us to track the status of long-running requests.