qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: REST API for AMQP management?
Date Fri, 29 Aug 2014 21:24:53 GMT
On Fri, 2014-08-29 at 23:09 +0200, Rob Godfrey wrote:
> Can you give an example of how you would create / read / update / delete a
> named object of a given type through this API.
> 
> Are you using the name or the identity field as the identifier to generate
> the URI for the "resource" being described?

I am assuming some fairly straightforward conversion between AMQP
Management messages and HTTP requests. My first thought is to use JSON
but there may be other more appropriate serializations. I would be
inclined to use identity for the URI.

I find the name/identity duality in AMQP management to be a serious
pain. I would get rid of name. We need an immutable identity for every
object. If some objects also need a mutable name, just give them an
attribute "name". If you want to be able to search by name, then
introduce a "query by attribute value" that would be more generally
useful than for just name attributes. That would make the spec simpler
and more powerful.

Cheers,
Alan.

> 
> -- Rob
> 
> 
> On 29 August 2014 22:59, Alan Conway <aconway@redhat.com> wrote:
> 
> > On Fri, 2014-08-29 at 19:45 +0000, Gibson, Jack wrote:
> > > Alan -
> > >
> > > I have been playing with vertx to amqp 1.0 set of restful services to
> > > manage dispatch routers.  So, I wouldn┬╣t mind helping out.  Let me know
> > to
> > > engage.
> > >
> >
> > I've been distracted for a while so I need to get my head back into the
> > dispatch management code. I have some work to finish up, mostly merging
> > functionality from the old C agent into the new python agent.
> >
> > The python agent is basically a schema validater and dispatcher of AMQP
> > management requests into the C code. The management requests and
> > responses are essentially just name/value maps or lists of maps. The
> > type system is simple for now: strings, bools, integers and floats. I
> > doubt it will get much more complicated than that.
> >
> > So I think for REST all we need is a HTTP server (presumably the default
> > python one would do) that converts HTTP requests to and from a
> > router.Message with python maps as properties and body. The management
> > code is already quite JSON friendly so that might be an easy way to do
> > it.
> >
> > Have a look at
> > dispatch/python/qpid_dispatch_internal/management/agent.py
> >
> > Agent.receive() is wired up to get AMQP management messages. It calls
> > Agent.handle() to process the message, and returns an AMQP response.
> >
> > The REST listener would be similar to receive() - create a request from
> > the HTTP request, feed it to Agent.handle() and convert the response to
> > a HTTP response.
> >
> > We can tidy things up a bit to make a clean interface between REST, AMQP
> > messages and whatever other feeds might come along and a more generic
> > Agent. With a clean API we should be able to re-use the same REST code
> > for inside dispatch, in your vertx services, or as a stand alone tool
> > that converts between REST and AMQP, or in tools for managing Qpid or
> > other AMQP services. I want to separate and make public the AMQP
> > management client for scripting, so that could be the basis of a
> > stand-alone REST to AMQP gateway.
> >
> > Let me know what you think!
> > Cheers,
> > Alan.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message