[occi-wg] Removing associations between resources

[Alexander Papaspyrou]

Personally, I think this is a really bad idea, since we are breaking the traditional semantics of HTTP and REST.

If there is a need for a lifecycle of a link, then the link should be a resource, and not some header construct. Otherwise, it should never be altered by the client, but instead, fully managed by the server. That is, if a resource gets deleted, the server should be responsible for finding and updating all dangling links and, on the next GET or HEAD for any affected resource, return the correct data.

Really, guys -- we are imposing additional CRUD semantics on the headers here. Shouldn't do that, though.

-Al.

Am 10.08.2010 um 15:09 schrieb Ralf Nyren:

> On Tue, 10 Aug 2010 10:21:38 +0200, Edmonds, AndrewX  
> <andrewx.edmonds at intel.com> wrote:
> 
> Hi Andrew, thanks for your response!
> 
>> Semantics related to removal/deletion of Link, in my view should be  
>> divided into two separate but complimentary areas:
>> 1) Unlinking - to unlink one resource from another the use of PUT should  
>> be used to update the appropriate resource
> 
> I agree, the use of PUT to remove an association between two resources is
> how I would want it.
> 
> The question is though, how to express the removal operation using the
> Link header?
> 
>> 2) Destroying a link - to destroy a link resource it must be unlinked  
>> from dependent resources using PUT and then finally destroyed using  
>> DELETE. If a user attempts to destroy before unlinking then the server  
>> should raise an exception. That way there are no dangling references to  
>> non-existent resources.
> 
> By a "link resource" you mean an association applied to a Resource, right?
> That is, an association/link can never exist on its own?
> 
> The way I view things the unlinking operation would not be necessary. Let
> us say we have a compute resource '/compute/vm01' and a storage resource
> '/storage/san01'. We then decide to associate these two resources by a  
> link.
> This can be accomplished by two different PUT request:
> 
> We could make a link from the compute resource to the storage resource,
> e.g. "add a disk":
> PUT /compute/vm01 HTTP/1.1
> Link: </storage/san01>; class='link'; rel=...
> 
> Or we could make a link from the storage resource to the compute resource,
> e.g. "make the disk available to the virtual machine".
> PUT /storage/san01 HTTP/1.1
> Link: </compute/vm01>; class='link'; rel=...
> 
> Now, since there is only one association here, removing either compute or
> storage resource would also destroy the association. An association between
> two resource can only exist as long as both resources exist.
> 
> If you view things this way you can never have dangling references.
> 
> What do think of this approach? I might just have misunderstood something
> though...
> 
> regards, Ralf
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg

-- 
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alexander Papaspyrou.vcf
Type: text/directory
Size: 498 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100810/3f182e57/attachment.bin 
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4678 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100810/3f182e57/attachment-0001.bin