As we do offer a means to interaction with the Link entity and we claim OCCI to be as RESTful as is possible then we need to respect aspects such as addressability and idempotency. The two ways we can offer interaction with Links are: 1) As a discrete entity with its own lifecycle. In this case addressability is required. Here the entity is subject to the full rules of HTTP verbs idempotency (PUT, DELETE, GET are idempotent). In this case the verb semantics are clearer when interacting with the Link entity (In general, I know I can GET, PUT, DELETE - POST is more a special case but issuing OPTIONS on the respective URI will tell me). 2) As a subordinate entity whose lifecyle is managed by its parent. As the entity's lifecycle is managed by its parent, the only entity that needs be addressable is the parent entity (note that makes the actual Link entity non-addressable). Also the Link entity is subject to idempotency of the parent entity and is interacted with HTTP verbs supported by the parent. The verb semantics are not as clear and potentially confusing as in 1) - I can't query the Link entity to see what HTTP operations _could_ be applied to allow me interact with the graph. Ralf makes a very good point, a PUT equates to a DELETE in this case and this is reflected in Ralf noting that the semantics are not reliable in deleting a Link. Really the PUT should be the action of Linking (or otherwise accomplished by actions [1]) and at the minimum updating attributes of the Link instance. Now that all said, each approach is valid; it just depends on how close to REST you want to be (we should always aim being very, very close ;-)). Andy [1] www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Wednesday, August 18, 2010 8:10 AM To: Michael Behrens Cc: Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] Revisiting Fat Links Michael,
In trying to digest all the link traffic (great stuff by the way) - can we perhaps assume that any POST or PUT operation would never destroy links.
POST would never destroy data in any of the three proposals. In the simple approach (called "Another proposal" in the wiki) a PUT request can indeed destroy Links. This is the big disadvantage of that approach. The Thin and Fat Link proposals do not have this problem.
Then, for removal of links, perhaps a separate DELETE call to the resource that specifies (somehow) only the deletion of the listed links is removed?
The problem is, with the simple approach, that you cannot reliable specify which Link to delete. Since a Link in this case is a composition of the Resource and is not a resource in itself there is no unique identifier. What you have is the target URI but there is nothing in the model which prevents you from linking multiple times to the same target. E.g. attaching two virtual interfaces to the same network. Thus you must specify the whole set of Links in every PUT request and any Links not present in that set must be removed by the server. With the Link as a REST resource as in the Thin/Fat Link proposals this is not a problem since the normal CRUD operations are allowed on individual Links. regards, Ralf ------------------------------------------------------------- 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.