Re: [openstack-dev] [nova][api] Allow passing body for more API methods
Hi all Thank you very much for your feedback, I found the discussion quick and useful. I'll abandon my change and for the bug fixing I'll pass a parameter in the DELETE. Regards -- ar -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 11 May 2015 19:29 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][api] Allow passing body for more API methods On 05/11/2015 11:53 AM, Sean Dague wrote: Why is DELETE /volumes/ID?force=true not an option? Yes, this is what I would recommend as well. Best, -jay __ 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
Re: [openstack-dev] [nova][api] Allow passing body for more API methods
(Added [api] to subject to bring in the attention of the API team.) On Mon, 2015-05-11 at 14:48 +, 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. 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. -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ 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
Re: [openstack-dev] [nova][api] Allow passing body for more API methods
On 05/11/2015 02:05 PM, Dean Troyer wrote: On Mon, May 11, 2015 at 11:44 AM, Rosa, Andrea (HP Cloud Services) andrea.r...@hp.com wrote: Agreed. Violating the HTTP spec is something that should be avoided. Actually it is not violating the HTTP spec, from RFC: A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. The RFC prohibit the use of a body just for the TRACE: A client MUST NOT send a message body in a TRACE request. When playing in undefined areas such as this it is best to keep in ming Jon Postel's RFC 1122 principle: Be liberal in what you accept, and conservative in what you send. I'll put it this way: An RFC not prohibiting something does not make it a good idea. This is not how we build a robust API that developers and user can easily adopt. ++ __ 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
Re: [openstack-dev] [nova][api] Allow passing body for more API methods
On Mon, May 11, 2015 at 11:44 AM, Rosa, Andrea (HP Cloud Services) andrea.r...@hp.com wrote: Agreed. Violating the HTTP spec is something that should be avoided. Actually it is not violating the HTTP spec, from RFC: A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. The RFC prohibit the use of a body just for the TRACE: A client MUST NOT send a message body in a TRACE request. When playing in undefined areas such as this it is best to keep in ming Jon Postel's RFC 1122 principle: Be liberal in what you accept, and conservative in what you send. I'll put it this way: An RFC not prohibiting something does not make it a good idea. This is not how we build a robust API that developers and user can easily adopt. dt Dean Troyer dtro...@gmail.com __ 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
Re: [openstack-dev] [nova][api] Allow passing body for more API methods
On May 11, 2015, at 1:05 PM, Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com wrote: On Mon, May 11, 2015 at 11:44 AM, Rosa, Andrea (HP Cloud Services) andrea.r...@hp.commailto:andrea.r...@hp.com wrote: Agreed. Violating the HTTP spec is something that should be avoided. Actually it is not violating the HTTP spec, from RFC: A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. The RFC prohibit the use of a body just for the TRACE: A client MUST NOT send a message body in a TRACE request. When playing in undefined areas such as this it is best to keep in ming Jon Postel's RFC 1122 principle: Be liberal in what you accept, and conservative in what you send. I'll put it this way: An RFC not prohibiting something does not make it a good idea. This is not how we build a robust API that developers and user can easily adopt. I’m agreed that this is not a good idea. I’d also invoke the principle of least astonishment here. Because it’s a de facto standard (so much so that some proxy in the middle may alter or reject such a request), it would be surprising to developers to allow such requests. REST APIs are difficult enough. Let’s avoid things with no defined semantics. I’d comment on the review but Gerrit is having a fit so I filed a bug. https://code.google.com/p/gerrit/issues/detail?id=3361 Everett __ 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
Re: [openstack-dev] [nova][api] Allow passing body for more API methods
On 05/11/2015 11:53 AM, Sean Dague wrote: Why is DELETE /volumes/ID?force=true not an option? Yes, this is what I would recommend as well. Best, -jay __ 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
Re: [openstack-dev] [nova][api] Allow passing body for more API methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/11/2015 01:49 PM, Everett Toews wrote: I’m agreed that this is not a good idea. I’d also invoke the principle of least astonishment here. Because it’s a de facto standard (so much so that some proxy in the middle may alter or reject such a request), it would be surprising to developers to allow such requests. REST APIs are difficult enough. Let’s avoid things with no defined semantics. Wise words. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVUSzzAAoJEKMgtcocwZqLt5QP/iZXNAsNjR5TSfdTTIeX4zpY U1NjVjR83AMmwLord9iFS2L2eOjkVWyNxCuxtVVK5yunYf3nRn3xNN/3WSDZezaf YRpAiKWmQrwT6wX2mNsegENxJbrgfkatXzhUsfrNrOc+Q+Y1YzYkbfVq1fmiHM28 FfkOCEOe/WZpWBG2hMcZfO++BBadLosYbYetSlwSgEGjy56epeGtpSeK/bnNxDCp R7ujKwP+QQuyUEEm6bqr/hqCS4ryzbVtSh8T1XCwiUcZ2LN4e4WIkNoZ5I3LWHm7 +ZUivYcQnTf+SdLqxk4QYriYf42Nz5XY6FhYhO9Kbxwfzdmj8y9PV4Jra8B5I0F4 bJ6Nw6X5x3lUarym9MCRV2qfFbfnvz4HwECNqG/1oyClGRRQkkFI8RPN665mHDtb JQBf+YxKmcPRu73kume2Kr/9I5YAA2hnqOQtTa8uuXCUHlftZ/OeXjB/pcDVW5U2 kLapxb6PoA4k5WEN4jtG2XcxonbwkGhxgRLA+ah3on2s9xMDl0EHJANnm7/PMuzp ZP0ln+66Gai/J48YNMw4dhV0sY/E2FC28mhrlS8TDwjE6UDAeaxTGL/HgkbcVdX7 A/FxJDco8Q1f53XtYBQ6vsV+t7y6MVauZxs7kp2clA7gJJSeFujb6w3AOA+Uct+l 7jq3kykx0rKin+NfoOR9 =EuC+ -END PGP SIGNATURE- __ 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
Re: [openstack-dev] [nova][api] Allow passing body for more API methods
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 +, 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 __ 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
Re: [openstack-dev] [nova][api] Allow passing body for more API methods
On 11 May 2015 at 18:53, Sean Dague s...@dague.net wrote: 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. There's nothing in the HTTP spec to prevent sending a body with a DELETE, that's what it means above about being more RFC compliant - nothing in the RFC prohibits this that I can spot, it's just a loose convention. -- Duncan Thomas __ 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
Re: [openstack-dev] [nova][api] Allow passing body for more API methods
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 am not 100% sure that it would be considered RESTful as it could violates some REST principlebut I think we do not want to open this discussion. So yes it could be a good compromise for the specific issue, my proposal was for a more general case. Agreed. Violating the HTTP spec is something that should be avoided. Actually it is not violating the HTTP spec, from RFC: A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. The RFC prohibit the use of a body just for the TRACE: A client MUST NOT send a message body in a TRACE request. Thanks -- Andrea Rosa __ 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
