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.
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?
Best,
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
