On 3/23/11 3:19 PM, André Dietisheim wrote:
Hi Jason
thanks for the further insights!
> There is an HTTP interface that can take requests in either JSON or in
> base64 encoded dmr binary format. We don't call it REST though because
> "invoking" an arbitrary management operation (e.g. "clear auth
cache")
> does not meet the REST purity definition.
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.
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.
>
> Keep in mind that the remote Java API will be the easiest to use from
> Java, since it will handle all the transport stuff for you, and
> exposes a nice API for working with detyped data. The main focus of
> the HTTP interface is supporting non-Java clients (i.e. scripting
> languages, and the console which is JavaScript based)
>
oh, looks like I missed this one. Guess using the java API would be the
better choice for me then. Is there any documentation about it?
Right now we just have:
http://community.jboss.org/wiki/FormatofaDetypedOperationRequest
Also see the code fro the management demos.
--
Jason T. Greene
JBoss, a division of Red Hat