<div dir="ltr">Regarding Jay's proposal, this would be tantamount to defining an API action for retrieving instances, something currently being discussed here [1].<div>The only comment I have is that I am not entirely surely whether using the POST verb for operations which do no alter at all the server representation of any object is in accordance with RFC 7231.<br><div>A search API like the one pointed out by Julien is interesting; at first glance I'm not able to comment on its RESTfulness - it definitely has plenty of use cases and enables users to run complex queries; one possible downside is that it increases the complexity of simple queries.</div><div><br></div><div><div>For the purpose of the Nova spec I think it might be ok to limit the functionality to a "small number of instance ids" as expressed in the spec.</div><div>On the other hand how crazy it would be to limit the number of bytes in the URL by allowing to specify contract form of instance UUIDs - in a way similar to git commits?</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/234994/">https://review.openstack.org/#/c/234994/</a></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 November 2015 at 13:17, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/03/2015 05:45 AM, Julien Danjou wrote:<br>
> On Tue, Nov 03 2015, Jay Pipes wrote:<br>
><br>
>> My suggestion was to add a new POST /servers/search URI resource that can take<br>
>> a request body containing large numbers of filter arguments, encoded in a JSON<br>
>> object.<br>
>><br>
>> API working group, what thoughts do you have about this? Please add your<br>
>> comments to the Gerrit spec patch if you have time.<br>
><br>
> FWIW, we already have an extensive support for that in both Ceilometer<br>
> and Gnocchi. It looks like a small JSON query DSL that we're able to<br>
> "compile" down to SQL Alchemy filters.<br>
><br>
> A few examples are:<br>
>   <a href="http://docs.openstack.org/developer/gnocchi/rest.html#searching-for-resources" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/gnocchi/rest.html#searching-for-resources</a><br>
><br>
> I've planed for a long time to move this code to a library, so if Nova's<br>
> interested, I can try to move that forward eagerly.<br>
<br>
</span>I guess I wonder what the expected interaction with things like<br>
Searchlight is? Searchlight was largely created for providing this kind<br>
of fast access to subsets of resources based on arbitrary attribute search.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>