Hi all, After more discussions and writing a sample implementation of the Link as a resource concept I have come to realize its advantages. I do however still believe that Fat Links are necessary to be able to model all relevant use cases. Alexander pointed out that compared to his Thin Link proposal Fat Links would not integrate in a sufficiently clean way with the OCCI core model. In an attempt to address some of these concerns I have added a new section called "Revisiting Fat Links" to the Link & Linking page [1]. The changes from the previous Fat Links proposal are: - Link specialization is realized through the use of additional categories, i.e. the same way OCCI Resource resources are extended so is also the Link resource extended. - The class attribute is _not_ used to delegate the Link type. It merely says that the link MAY be specialized. It is an indication to the client to request Link details. - The rel attribute is used to delegate the type of the Link target, i.e. as suggested by the Web Linking draft. Comments welcome. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
You'll probably want to bash me, Ralf, but I have always favoured your initial suggestion ("Another proposal") :-). Main reason is that without a second call, as in the case with this new proposal, I can get the type information of both the link and target resource and _also_ the attributes of that link, in the examples shown, a specialized Link. Where one aspect of confusion or debate arises with your initial suggestion is the idea that if a model entity has a Category associated with it, the entity must then be a Resource. I don't quite see it this way. Rather, I see the addition of a Category to any (R)resource (except Category itself, that's non-sensical) as a means of signaling type information. Andy PS: I hope I'm not repeating an earlier argument of someone elses. -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Tuesday, August 17, 2010 5:50 PM To: occi-wg@ogf.org Subject: [occi-wg] Revisiting Fat Links Hi all, After more discussions and writing a sample implementation of the Link as a resource concept I have come to realize its advantages. I do however still believe that Fat Links are necessary to be able to model all relevant use cases. Alexander pointed out that compared to his Thin Link proposal Fat Links would not integrate in a sufficiently clean way with the OCCI core model. In an attempt to address some of these concerns I have added a new section called "Revisiting Fat Links" to the Link & Linking page [1]. The changes from the previous Fat Links proposal are: - Link specialization is realized through the use of additional categories, i.e. the same way OCCI Resource resources are extended so is also the Link resource extended. - The class attribute is _not_ used to delegate the Link type. It merely says that the link MAY be specialized. It is an indication to the client to request Link details. - The rel attribute is used to delegate the type of the Link target, i.e. as suggested by the Web Linking draft. Comments welcome. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- 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 Tue, 17 Aug 2010 19:10:43 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
You'll probably want to bash me, Ralf, but I have always favoured your initial suggestion ("Another proposal") :-). Main reason is that without a second call, as in the case with this new proposal, I can get the type information of both the link and target resource and _also_ the attributes of that link, in the examples shown, a specialized Link.
I agree, it is nice to have all information in one request. Those things among others are what I like with the simple approach. Two main reasons I would favor the Fat Links approach instead though: - Update of Links for a Resource is a problem in the simple approach. Links become a special case and you must always supply all Links in a PUT request. It is indeed more clean to have PUT only update attributes and nothing else. - You can only have _one_ Category associated with a Link, i.e. no composite types. I have added a sample UML diagram of the Core Model supporting Fat Links to the Link wiki page. I included the resource (lower case 'r') concept in the diagram to illustrate the distinction between a resource and a Resource.
Where one aspect of confusion or debate arises with your initial suggestion is the idea that if a model entity has a Category associated with it, the entity must then be a Resource. I don't quite see it this way. Rather, I see the addition of a Category to any (R)resource (except Category itself, that's non-sensical) as a means of signaling type information.
Hmm... yes I do also see the assignment of Categories as signaling type information. It makes things flexible and extensible in a well defined way. Might be useful to draw an UML diagram of the simple approach just to clarify things. regards, Ralf
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. 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? Sorry if I've missed a comment about that already. Ralf Nyren wrote:
On Tue, 17 Aug 2010 19:10:43 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
You'll probably want to bash me, Ralf, but I have always favoured your initial suggestion ("Another proposal") :-). Main reason is that without a second call, as in the case with this new proposal, I can get the type information of both the link and target resource and _also_ the attributes of that link, in the examples shown, a specialized Link.
I agree, it is nice to have all information in one request. Those things among others are what I like with the simple approach.
Two main reasons I would favor the Fat Links approach instead though: - Update of Links for a Resource is a problem in the simple approach. Links become a special case and you must always supply all Links in a PUT request. It is indeed more clean to have PUT only update attributes and nothing else. - You can only have _one_ Category associated with a Link, i.e. no composite types.
I have added a sample UML diagram of the Core Model supporting Fat Links to the Link wiki page. I included the resource (lower case 'r') concept in the diagram to illustrate the distinction between a resource and a Resource.
Where one aspect of confusion or debate arises with your initial suggestion is the idea that if a model entity has a Category associated with it, the entity must then be a Resource. I don't quite see it this way. Rather, I see the addition of a Category to any (R)resource (except Category itself, that's non-sensical) as a means of signaling type information.
Hmm... yes I do also see the assignment of Categories as signaling type information. It makes things flexible and extensible in a well defined way.
Might be useful to draw an UML diagram of the simple approach just to clarify things.
regards, Ralf _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) (703) 714-0442 (land)
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
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.
participants (3)
-
Edmonds, AndrewX -
Michael Behrens -
Ralf Nyren