HTTP Doc and Resource Updates
I'd be interested to hear how people currently implement updates to their various OCCI resources. Currently in the spec, it says to perform a PUT and supply _only_ the attributes that need to be updated. This works and is clear in changing or adding items such as attributes or mixins. However what is not so clear to me is how to handle an update that removes a mixin from an existing resource (e.g. I want to remove IP networking capabilities). One solution I suggest would be that the section on updating a resource allow for updating using both POST and PUT. In this case POST can modify (i.e. replace) a _part_ of the resource e.g. a particular attribute. PUT can replace the whole resource _representation_ and in doing so support the removal of items like mixins. Comments? Andy ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Add/remove of Mixins is handled using PUT/DELETE at the location path of the Mixin. See HTTP Rendering page 8 paragraph "Associate resource instances with a Mixin" and "Unassociated resource instance(s) from a Mixin". The occi-py library implements this part of the specification. I basically only use PUT on a resource to update attributes. Links (link-attributes, removal, etc) I handle through the Link location itself. I think the spec works fine as written. It is all up and running at http://www.nyren.net/api/ so you are welcome to try it out =) regards, Ralf On Thu, 31 Mar 2011 17:28:44 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
I'd be interested to hear how people currently implement updates to their various OCCI resources. Currently in the spec, it says to perform a PUT and supply _only_ the attributes that need to be updated.
This works and is clear in changing or adding items such as attributes or mixins. However what is not so clear to me is how to handle an update that removes a mixin from an existing resource (e.g. I want to remove IP networking capabilities).
One solution I suggest would be that the section on updating a resource allow for updating using both POST and PUT. In this case POST can modify (i.e. replace) a _part_ of the resource e.g. a particular attribute. PUT can replace the whole resource _representation_ and in doing so support the removal of items like mixins.
Comments?
Andy
My bad! Gah... Ralf next time feel free to reply with RTFM! :-) Thanks! BTW: personally, with working with REST I'd have preferred the operation on the resource as opposed to the resource related to the resource in question but none the less that's only a digression. -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Thursday, March 31, 2011 9:20 PM To: Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] HTTP Doc and Resource Updates Add/remove of Mixins is handled using PUT/DELETE at the location path of the Mixin. See HTTP Rendering page 8 paragraph "Associate resource instances with a Mixin" and "Unassociated resource instance(s) from a Mixin". The occi-py library implements this part of the specification. I basically only use PUT on a resource to update attributes. Links (link-attributes, removal, etc) I handle through the Link location itself. I think the spec works fine as written. It is all up and running at http://www.nyren.net/api/ so you are welcome to try it out =) regards, Ralf On Thu, 31 Mar 2011 17:28:44 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
I'd be interested to hear how people currently implement updates to their various OCCI resources. Currently in the spec, it says to perform a PUT and supply _only_ the attributes that need to be updated.
This works and is clear in changing or adding items such as attributes or mixins. However what is not so clear to me is how to handle an update that removes a mixin from an existing resource (e.g. I want to remove IP networking capabilities).
One solution I suggest would be that the section on updating a resource allow for updating using both POST and PUT. In this case POST can modify (i.e. replace) a _part_ of the resource e.g. a particular attribute. PUT can replace the whole resource _representation_ and in doing so support the removal of items like mixins.
Comments?
Andy
------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Thu, 31 Mar 2011 20:57:58 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
BTW: personally, with working with REST I'd have preferred the operation on the resource as opposed to the resource related to the resource in question but none the less that's only a digression.
It would indeed make it more RESTful and clever move there to keep the old functionality (which at least I find quite useful) through POST. I give my vote for the change if and only if we update the HTTP Rendering spec to include explicit ABNF grammar for each different use case for the Category and Link headers. For example, a Link header in a PUT /compute/123 MUST have the self= parameter specified but MUST NOT have any Link attributes specified. The Link title parameter is also a MUST NOT in this case since it refers to the title of the target resource. Maybe we can just break it down into 2 use cases per header, i.e. Link header ABNF for requests and Link header ABNF for responses. The change is good but there are all these little details that could cause lots of interoperability problems if we do not specify them very precisely. regards, Ralf
participants (2)
-
Edmonds, AndrewX -
Ralf Nyren