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 <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
