Open Stack

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