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