> This looks just right for a one-many link (as in my #1 option --
> post to a
> cart "collection" resource) in which the "one" is obvious and easily
> discoverable (like a cart). But a common case I run into is a one
> in which
> a resource must be linked to any of a large number of possible related
> resources. (In my case it is a digital image library, in which we
> regularly
> need to create links between items, e.g., a link from a photo of an
> architect to an image of a building that she created.). We have
> needed to
> devise as general an operation as possible to *relate* two
> resources. In
> the case of a cart and a product, it is obvious what the
> relationship will
> be once it is created. We have need to create links between
> resources that
> may have any of a large number of relations (e.g., "created-by"). I
> wish to
> stay in the realm of Atom (avoiding complexities of RDF). I am
> reminded
> somewhat here by the work going on in activities streams....
> Anyway, I
> agree with Sam that it is currently an unsolved problem with wide
> applicability.
>

So, when you let clients establish links between resources, who
controls whether a link is valid or bogus?

What is the advantage of the client owning this problem?

Forgetting about HTTP and REST for a bit, would you still take the
same approach if you are building this application using a different
style? What I am getting at is, is the "link management" problem real,
or is it a manifestation of an implementation choice?

Subbu