On Tue, 10 Aug 2010 10:21:38 +0200, Edmonds, AndrewX <andrewx.edmonds@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