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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
