Inline, Salvatore On 4 November 2015 at 15:11, Cory Benfield <c...@lukasa.co.uk> wrote:
> > > On 4 Nov 2015, at 13:13, Salvatore Orlando <salv.orla...@gmail.com> > wrote: > > > > Regarding Jay's proposal, this would be tantamount to defining an API > action for retrieving instances, something currently being discussed here > [1]. > > 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. > > 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. > > 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. > > 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. > 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. > > 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. > I believe there will be not a great advantage from caching this kind of responses, as cache hits would be very low anyway. > Cory > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
