<div dir="ltr"><br><div class="gmail_extra">Inline,</div><div class="gmail_extra">Salvatore</div><div class="gmail_extra"><br><div class="gmail_quote">On 4 November 2015 at 15:11, Cory Benfield <span dir="ltr"><<a href="mailto:cory@lukasa.co.uk" target="_blank">cory@lukasa.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 4 Nov 2015, at 13:13, Salvatore Orlando <<a href="mailto:salv.orlando@gmail.com">salv.orlando@gmail.com</a>> wrote:<br>
><br>
> Regarding Jay's proposal, this would be tantamount to defining an API action for retrieving instances, something currently being discussed here [1].<br>
> 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>
<br>
</span>It’s totally fine, so long as you define things appropriately. Jay’s suggestion does exactly that, and is entirely in line with RFC 7231.<br>
<br>
The analogy here is to things like complex search forms. Many search engines allow you to construct very complex search queries (consider something like Amazon or eBay, where you can filter on all kinds of interesting criteria). These forms are often submitted to POST endpoints rather than GET.<br>
<br>
This is totally fine. In fact, the first example from RFC 7231 Section 4.3.3 (POST) applies here: “POST is used for the following functions (among others): Providing a block of data […] to a data-handling process”. In this case, the data-handling function is the search function on the server.<br></blockquote><div><br></div><div>I looked back at the RFC and indeed it does not state anywhere that a POST operation is required to change somehow the state of any object, so the approach is entirely fine from this aspect as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The *only* downside of Jay’s approach is that the response cannot really be cached. It’s not clear to me whether anyone actually deploys a cache in this kind of role though, so it may not hurt too much.<br></blockquote><div><br></div><div>I believe there will be not a great advantage from caching this kind of responses, as cache hits would be very low anyway.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Cory<br>
<br>
<br>
</font></span><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>
<br></blockquote></div><br></div></div>