On Tue, Jan 28, 2014 at 1:39 PM, Fraser Adams <fraser.ad...@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 http://127.0.0.1:8080/qpid/connection/default/console/objects/queuerather > than say > GET http://127.0.0.1:8080/qpid/console/objects/queue > > 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
