qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: REST API for AMQP management?
Date Fri, 29 Aug 2014 21:58:01 GMT
So, the other aspect that could be considered in a REST API is whether the
type should form part of the URI.  The REST API URIs of both RabbitMQ and
the Java Broker look something like /api/<type>/<name-path>.  So for
instance a queue might be addressed by /api/queue/myvhost/myqueue.  This
also allows for the expected behaviour of /api/queue/myvhost to bring back
the collection of all "queue" objects on the virtualhost vhost.  If we
think of this as being /api/<type>/<name> in an AMQP management sense then
it would lead to the conclusion that when viewed at the level of a broker
which has multiple virtual hosts a queue name might be considered to be
"<virtualhostname>/<queue name>" whereas if the management operation was
constrained to viewing only a single virtual host then the "name" observed
at that management node would simply be "<queue name>".

-- Rob


On 29 August 2014 23:35, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:

> 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 <aconway@redhat.com> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message