Hi, Thank you all for the comments, see mines inline.
Best Regards and Merry Christmas, Ildiko -----Original Message----- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Tuesday, December 24, 2013 2:14 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ceilometer] Complex query BP implementation On 12/24/2013 04:23 AM, Julien Danjou wrote: > On Tue, Dec 24 2013, Jay Pipes wrote: > >> My main objection to the proposed solution is that it violates the >> principle in all of the OpenStack REST APIs that a POST request *creates* a >> resource. >> In the proposed API, you use: >> >> POST /query/$resource >> >> to actually retrieve records of type $resource. In all the other >> OpenStack REST APIs, the above request would create a $resource >> subresource of a "query" resource. And, to be honest, people expect >> HTTP REST APIs to use the GET HTTP method for querying, not POST. >> It's an anti-pattern to use POST in this way. > > I thought the same, but it seems that actually using GET with a body > isn't terribly standard, though not strictly disallowed AFAIU. So I > think supporting both, GET for sanity and POST for compatibility, > would make sense. I think you may have switched the above? Do you mean POST for sanity (short URLs) and GET for compatibility/standards? Using GET with a request body is really not a common practice. ildikov: There is a risk with using GET request with a body that some routers or proxies will drop the body as it is so unexpected. It is more common to use POST for rich queries, than GET with body. ildikov: Currently nothing blocks us to use both. As I mentioned in my previous mail, the actual simple query feature and our solution are independent from each other, so using the new implementation will not affect the currently existing one. >> Now, that said... I think that the advanced query interface you >> propose does indeed have real-world, demanded use cases. Right now, >> you are 100% correct that the existing GET request filters are >> simplistic and don't support either aggregation or advanced union or >> intersection queries. >> >> I would definitely be supportive of using POST to store "saved >> queries" (as you mention in your wiki page). However, the main query >> interface should remain the GET HTTP method, including for ad-hoc advanced >> querying. > > Storing queries doesn't sound like something we would want to do. Can you elaborate why this is not something Ceilometer would be interested in supporting? Would you prefer this kind of thing live in some other component? ildikov: I think stored query support can be a user value in the future. But first we need to see the behavior of the databases under heavy load and then we can plan with features like this. But correct me, if I'm wrong here. Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
