Subbu Allamaraju wrote:
>
>
>
> Sam,
>
> I don't disagree that there are use cases, but I am not sure if
> letting clients manage relations is the right way to implement
> distributed systems. The approach you describe below is similar to a
> client trying to setup foreign key relations between different
> database entities. This model leaks abstractions and is not ideal for
> writing large systems.
>
> For instance, take a simple shopping cart application. The server may
> have decided to use links to associate products to a cart, but that
> does not mean that, clients should be able to create/edit/delete those
> links. Instead, links come into being when the client "adds products
> to a cart" and they go away when the client "removes a product from
> the cart". That is the right level of abstraction for the client.
>
> IMO, links are for servers to provide navigability between resources,
> and to let clients make state transitions via links.
>

Let's leave aside the issue on whether to introduce LINK and UNLINK.
What about the value of Link headers themselves? I really like the idea
of propogating additional metadata about the resource without polluting
the resource. Sometimes you just can't modify the resource (image).


Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com