[occi-wg] Revisiting Fat Links

[Edmonds, AndrewX]

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 at nyren.net]
Sent: Wednesday, August 18, 2010 8:10 AM
To: Michael Behrens
Cc: Edmonds, AndrewX; occi-wg at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100818/947f6867/attachment.bin 
-------------- next part --------------
-------------------------------------------------------------
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.