qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shearer, Davin" <dshea...@novetta.com>
Subject Re: QMF REST API - was Re: How to use lifetime policies
Date Tue, 28 Jan 2014 19:18:41 GMT
On Tue, Jan 28, 2014 at 1:39 PM, Fraser Adams <fraser.adams@blueyonder.co.uk
> wrote:

> Glad that I was able to help out.
> I'm a little bit curious why you're choosing to go with the REST interface
> directly? What language are you programming in.

I am programming this piece in C (messaging and transport layer of a larger
system).  I am using proton for the AMQP layer and using the REST API for
the broker management.  I like the decoupling that REST provides as it just
takes a library that speaks HTTP.  I don't have to link against a
vendor-specific management library nor do I have to carry through their
dependencies.  I don't want the consumers of the library (be it additional
middle-ware layers or the application-layer code) to be concerned about the
messaging and transport details, just that we moving data reliably from one
end-point to another over a flexible topology.

> Not that I've got anything against the REST API, but I mainly put it in
> place to be able to talk QMF from a browser environment.

It should work for my needs as well.  It took longer than I'd hoped to
package a "reference" broker, but I've managed it.

> I've attached a couple of examples put together by Gordon Sim to
> illustrate this in C++ the queue_depth is self explanatory, the one marked
> example.cpp does something similar to qpid-route - not exactly what you
> want for adding a queue, but it illustrates invoking QMF2 methods via the
> raw QMF2 protocol and you can use that in conjunction with what I've shown
> below on the REST API

I think your REST API will be sufficient provided I request a dynamic queue
with delete on close via REST.  If that isn't possible then it could be the
case that there will be abandoned reply queues lingering in the broker if a
client creates one, then dies without removing it.  I will review the code
since more information usually leads to better decisions.

> It is quite fun doing this stuff via curl, but it's pretty hardcore :-)
> I'd *probably* take easier options in Python/Java/C++/JavaScript unless I
> wanted to prove a point (clearly REST is handy if you want to mash up info
> from lots of different sources in a web app).

The commandline curl stuff is to understand the API, get my URLs right and
to test the behaviour before writing it up in C using libcurl.

> BTW in case you are curious the reason that the URI's are relatively
> complex e.g.
> GET than say
> Is because it's perfectly possible to PUT an arbitrary number of QMF
> Console connections and access them independently so the GUI can talk to
> multiple discrete Consoles and I can have multiple browser instances served
> by the same REST API instance.

I think the flexibility that provides is worth the price in complexity.  I
only have to get it right once, then it's in my library and I'll build on
top of that. :-)

I hope that helpful and that it made sense...

Davin Shearer

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message