Hi Jason
> hmm, to be honest I dont really understand why a RESTy semantic
(ex.
> post to or delete to the uri of the cache resource) would not allow this
> operation. But I might miss something here since I do not have the same
> background.
It's purely an issue of complexity. A more RPC approach has the
benefit that any subsystem can expose any runtime call it wishes to by
just adding a method and a mapping. In a REST approach you have to
come up with clever ways to map what ever you are doing to a CRUD
resource tree, this puts a lot of burden on subsystem developers.
I obviously lack the knowledge about your requirements and the way the
subsystems communicate with the service interface.
I agree with you about the complexity in providing a consistent URI
space (~mapping). But I'd argue that you have the same design decisions
in classic RPC style, too. In the end REST style just offers you to
model operations on URI's and HTTP methods instead of RPC method
parameters.
Also note that we support complex transactional operations (e.g.
apply
this change to 15 servers and if more than 4 of them fail roll it
back) which do not map cleaning to a simple READ/UPDATE/DELETE URL
model. You end up having to create virtual session specific objects
for every client.
I'd argue that the mapping challenge is a matter of design and not the
inability in REST to offer transactions. I usually impleted this in a
transaction resource that was PUT the operations to (which then are
usually a set of URI of the resource to manipulate, the method to use
and ev. params).
Cheers
André