[openstack-dev] [nova][api] Allow passing body for more API methods

Sean Dague sean at dague.net
Mon May 11 15:53:52 UTC 2015


On 05/11/2015 11:39 AM, Kevin L. Mitchell wrote:
> (Added [api] to subject to bring in the attention of the API team.)
> 
> On Mon, 2015-05-11 at 14:48 +0000, Rosa, Andrea (HP Cloud Services)
> wrote:
>> I noticed that in the nova API we allow to specify body just for the
>> PUT and POST requests [0], for all the other methods, if a body is
>> specified, it gets ignored.
>>
>> I had a look at the RFC 7231 [1] and I noticed that just the TRACE
>> must not have a body, for all the other request a body can be passed
>> and managing or ignoring it depends  on the semantic of the request.
>>
>> For that reason my proposal is to allow at WSGI layer to define a body
>> for all the requests but for the TRACE then it is up to the specific
>> controller to ignore or deal with the body in the request.
>>
>> I put a WIP to implement that change [3].
>>
>> The rationale behind it is double:
>>
>> -         Be more in compliance with the RFC
>>
>> -         Having  more flexibility in our framework. I have a valid
>> (at least for me) use case here [4]:  at the moment a volume detach is
>> implemented using a HTTP DELETE, I’d like to add the option for
>> calling from nova, the cinder –force-delete
>>
>> My idea to implement it is to add a parameter in the body of the
>> DELETE call, but at the moment the only valid option is to create a
>> new API using a POST method.

Why is DELETE /volumes/ID?force=true not an option?

I believe it's valid for DELETE method to take parameters. Just not a body.

> I have worked with client frameworks which raise exceptions if you
> attempt to pass a body using the DELETE method, and would presumably
> also prohibit a body with GET and HEAD, so I'm -1 on this: we should
> actively discourage service developers from requiring bodies on HTTP
> methods that a client framework may prohibit sending bodies with.

Agreed. Violating the HTTP spec is something that should be avoided.

(also it provides more fodder for the http clarification section of the
api-wg repo).

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list