Open Stack

On 12/7/2016 2:40 AM, Sylvain Bauza wrote:
>
> FWIW, I think POST is not that complex and allows us to have room for
> further request information like traits, without defeating the purpose
> to have something RESTful.
>
> The proposal is up, comments welcome
> https://review.openstack.org/#/c/392569/
>
> -Sylvain
>

Just to update everyone else following along, we had a discussion in IRC 
today (me, edleafe, bauzas, sdague, cdent and dansmith) about GET vs 
POST and the majority of us sided with simple GETs for now, knowing we 
have the option to do complex POST requests later with a microversion if 
it turns out that we need it.

I was originally wanting to do the POST request but wasn't fully aware 
of the future plans to POST to /allocations to make claims with a 
request spec which can have a complicated request body.

We also aren't doing traits right now, so while I'm not crazy about the 
namespaced query language that's going to get built into the GET query 
parameters, right now it's not a monster we need to deal with.

I don't want to underestimate the complexity that might blow up the GET 
query parameter schema, especially once we start having to deal with NFV 
use cases, but we aren't there yet and I'd rather not boil the ocean 
right now. Sean pointed out, as thankfully he usually does, that if we 
over-complicate this for future requirements we'll lose time working on 
what needs to get done for the majority of use cases that we want to 
have working in Ocata, so let's move forward with the more normal GET 
format for listing resource providers with filters knowing that we have 
options in the future with POST and microversions if we need that escape 
hatch.

-- 

Thanks,

Matt Riedemann