You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2014/08/29 21:40:22 UTC
REST API for AMQP management?
Does anybody out there have any experience or ideas about this? Has
anyone already defined a REST API corresponding to the AMQP management
spec? Anybody got experience with implementing such an API?
I am working on improving the AMQP 1.0 management support for the
dispatch router (implemented in python) and it seems like it would be
pretty easy to stick a little python REST API layer in there.
Let me know if you have any insights or are interested in contributing
to this.
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: REST API for AMQP management?
Posted by Gordon Sim <gs...@redhat.com>.
On 08/29/2014 08:45 PM, Gibson, Jack wrote:
> 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.
Interesting! I started playing with vert.x also, with the view to
providing a common management facade over various different brokers. I
started with rabbitmq (managed via HTTP) and qpidd (managed via QMFv2
over AMQP 1.0). It's super rough at the moment, I haven't had any time
to play for a while (nor am I likely to have any in the near future),
but it lets you create/delete and list queues on either broker either
over http or over a simple amqp 1.0 equivalent.
The code is at https://github.com/grs/qontroller, but is as I say very
rough and really just an experiment at this stage. I know the vert.x
project is eager to have good AMQP 1.0 support also.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: REST API for AMQP management?
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2014-08-29 at 23:58 +0200, Rob Godfrey wrote:
> 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>".
>
My reading of the management spec is that entity names and ids are
unique across all entities, not just across a type, so the type would be
redundant. You might want to query for an entity by name/id when you
don't know its type. I'm not dead set against including the type, just
not sure if it's the Right Thing.
You could query differently e.g. /api/query?type=queue
which would perhaps map more naturally onto AMQP management queries
which are a map of optional query parameters rather than a sequential
path.
As to virtual hosts, the C++ broker doesn't even have them so I would
think they are an (optional) part of the entity name that is interpreted
by the broker as appropriate.
> On 29 August 2014 23:35, Rob Godfrey <ro...@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.
We should let the user create an entity with a management name which is
user-specified. They can get the generated ID from the response. Since
we can't assume names and IDs won't clash it seems to me we need name
URIs and ID URIs. So you would create a new entity with URI like:
/api/name/foo
and get a response which includes "id=horribleServerGeneratedId". Then
you could query the entity using either of:
/api/name/foo
/api/id/horribleServerGeneratedId
I'm new to thinking about REST so all of the above is subject to change
when someone patiently explains things to me.
> > On 29 August 2014 23:24, Alan Conway <ac...@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 <ac...@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
> >>
> >>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: REST API for AMQP management?
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ro...@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 <ac...@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 <ac...@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
>>
>>
>
Re: REST API for AMQP management?
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ac...@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 <ac...@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
>
>
Re: REST API for AMQP management?
Posted by Alan Conway <ac...@redhat.com>.
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 <ac...@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
Re: REST API for AMQP management?
Posted by Rob Godfrey <ro...@gmail.com>.
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?
-- Rob
On 29 August 2014 22:59, Alan Conway <ac...@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
>
>
Re: REST API for AMQP management?
Posted by Alan Conway <ac...@redhat.com>.
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
Re: REST API for AMQP management?
Posted by "Gibson, Jack" <ja...@paypal.com.INVALID>.
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.
Jack
Gibson, Jack
Director - ebay, Global Platform Service
On 8/29/14, 2:40 PM, "Alan Conway" <ac...@redhat.com> wrote:
>Does anybody out there have any experience or ideas about this? Has
>anyone already defined a REST API corresponding to the AMQP management
>spec? Anybody got experience with implementing such an API?
>
>I am working on improving the AMQP 1.0 management support for the
>dispatch router (implemented in python) and it seems like it would be
>pretty easy to stick a little python REST API layer in there.
>
>Let me know if you have any insights or are interested in contributing
>to this.
>
>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
Re: REST API for AMQP management?
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Alan,
so the Java Broker doesn't currently have a REST API over the AMQP
Management protocol, but it does have a REST API for Management... and the
AMQP Management Model and the Java Broker Management model has very much
informed each other :-). I'm probably not able to contribute code to what
you are looking to do, but I think trying to get as much convergence
between what you are looking to do and what the Java Broker is/should be
doing would be a really good idea, so would be very keen to review mapping
design thoughts etc.
I think any such mapping of REST <-> AMQP Management should at least be
floated amongst at the OASIS AMQP technical committee as I think such a
mapping is generally useful.
Cheers,
Rob
On 29 August 2014 21:40, Alan Conway <ac...@redhat.com> wrote:
> Does anybody out there have any experience or ideas about this? Has
> anyone already defined a REST API corresponding to the AMQP management
> spec? Anybody got experience with implementing such an API?
>
> I am working on improving the AMQP 1.0 management support for the
> dispatch router (implemented in python) and it seems like it would be
> pretty easy to stick a little python REST API layer in there.
>
> Let me know if you have any insights or are interested in contributing
> to this.
>
> Cheers,
> Alan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>