My expectation (and the way the Java Broker works) is that the ID may well be a UUID... this doesn't make for a terribly easily human readable URI. The expectation is that the ID is generated by the server. This doesn't play terribly well with REST where the creation of the resource would be at the location given in the URI which would make it user rather than server supplied.
-- Rob On 29 August 2014 23:24, Alan Conway <[email protected]> wrote: > 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] > >
