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. > 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. -- Julien Danjou ;; Free Software hacker ; independent consultant ;; http://julien.danjou.info
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
