Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B307111FF2 for ; Fri, 29 Aug 2014 21:58:31 +0000 (UTC) Received: (qmail 72285 invoked by uid 500); 29 Aug 2014 21:58:31 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 72243 invoked by uid 500); 29 Aug 2014 21:58:31 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 72222 invoked by uid 99); 29 Aug 2014 21:58:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Aug 2014 21:58:31 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rob.j.godfrey@gmail.com designates 209.85.192.47 as permitted sender) Received: from [209.85.192.47] (HELO mail-qg0-f47.google.com) (209.85.192.47) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Aug 2014 21:58:03 +0000 Received: by mail-qg0-f47.google.com with SMTP id z60so2876898qgd.6 for ; Fri, 29 Aug 2014 14:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=JMqmSfAeGxfS8RAdnse4AaJ/+pAz5wJlYX34+0X/LBA=; b=fL0KCEXs9NEReijJMQnS2LIybCpPNOKusZsvA75BvNkyxfRJekM4VpmtTzygvrTerx x4PprlUF8q12JP6vecn5mL11dBFtzSxD0a2k6cGhYIaComZ31cJcgvnCdPq1yaC3LaaO W1bQygu8uezmkis6NPft3RWRfhzA9bNn3lak3LWT4J6DcHo0/K3O24MVXR5puGZpe9b2 SVEgsbjENex/2yn00/xZjHo+qsgckbWWjHklJRPPNpWBmLqu2BK/TU3ZjBEcJazeH7H8 eyvHuy8SkVL3XCqTTTA9GbGj/ASv4w8extiE3SukgNIsDdaLWopJR83Yl0x7oQCu7zY9 JI+A== MIME-Version: 1.0 X-Received: by 10.140.104.69 with SMTP id z63mr20820339qge.81.1409349481677; Fri, 29 Aug 2014 14:58:01 -0700 (PDT) Received: by 10.140.101.6 with HTTP; Fri, 29 Aug 2014 14:58:01 -0700 (PDT) In-Reply-To: References: <1409341222.13978.4.camel@localhost> <1409345959.13978.30.camel@localhost> <1409347493.13978.36.camel@localhost> Date: Fri, 29 Aug 2014 23:58:01 +0200 Message-ID: Subject: Re: REST API for AMQP management? From: Rob Godfrey To: "users@qpid.apache.org" Content-Type: multipart/alternative; boundary=001a11354780384c0d0501cbbf5a X-Virus-Checked: Checked by ClamAV on apache.org --001a11354780384c0d0501cbbf5a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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//. 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// 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 "/" 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 "". -- Rob On 29 August 2014 23:35, Rob Godfrey wrote: > My expectation (and the way the Java Broker works) is that the ID may wel= l > 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 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 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=C2=B9t mind helping out. L= et 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 manageme= nt >> > > 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 call= s >> > > 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 generi= c >> > > Agent. With a clean API we should be able to re-use the same REST co= de >> > > for inside dispatch, in your vertx services, or as a stand alone too= l >> > > that converts between REST and AMQP, or in tools for managing Qpid o= r >> > > 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 >> >> > --001a11354780384c0d0501cbbf5a--