Having problems with message search?
1. The server has a cart resource, and product resources.
2. Each product resource found in a search will have a link
<link rel="http://shop.org/rels/buy" href="http://shop.org/subbu/cart"/>
The definition of rel says that the client should use POST to add the product to the cart.
3. Client adds the product to the cart
POST /subbu/cart
Content-Type: application/xml
id=1234
4. Server redirects back to the updated cart
303 See Other
Location: http://shop.org/subbu/cart
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.
--peter
Â
This is just generalized version of a web based shopping cart, and provides a simplified interface to the client. As I said before, expecting the client to manage links is akin to clients posting SQL statements to servers.
Subbu
On Tue, Jun 30, 2009 at 11:59 AM, Subbu Allamaraju <subbu@...> 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.
Subbu
On Jun 30, 2009, at 3:44 AM, Sam Johnston wrote:
Hi Subbu,
On Tue, Jun 30, 2009 at 5:45 AM, Subbu Allamaraju <subbu@...<subbu%40subbu.org>>
wrote:http://ftp.ics.uci.edu/pub/ietf/http/draft-pritchard-http-links-00.txt
LINK is similar - how a LINK relationship is created/managed/undefined.
destroyed is
Why isn't that up to the server(s) managing the resources? Links are
for servers to describe relations between resources, and not for
clients to manage such relationships.
Why so? This use case requires that clients be able to manage links:
virtual
infrastructure is modeled as compute, storage and network resources
and
clients create, delete and link them as they see fit. The server can
too
(for example, implicitly creating a storage resource and linking it
when you
create a compute resource) but the point of OCCI
<http://www.occi-wg.org/>is to allow for client manipulation.
We're not the only ones who see a need either... the original
authors of the
HTTP spec (RFC 2068) including LINK and
UNLINK<http://tools.ietf.org/html/rfc2068#section-19.6.1.2>verbs for
this around the same as this
I-D <
specifyingsame in more detail. This is what Mark Nottingham (author of the
Link: header I-D among other things, copied) had to say this morning
on
apps-discuss:
*- First and foremost, in the absence of the LINK and UNLINK verbs
originally defined in RFC 2068[2] but specifically omitted from RFC
2616[3],
what is the preferred mechanism for manipulating these links via
HTTP? It
appears that this header is intended for GET requests only, but
presumably
specifying it in POST and PUT requests would be one option that
avoids the
creation of [not so] "new" verbs (bearing in mind that short of
accepting
Link: headers from empty POST/PUT requests, it would be necessary to
GET and
then PUT the entire payload to update links - twice if they were
reciprocal). While there was an attempt a dozen years ago to better
define
the relevant HTTP verbs[4], it strikes me as more sensible to follow
the
example of the Set-Cookie: header for this rather than WebDAV's
example of
creating new verbs (even if we've seen them before) but you guys are
the
experts.*
Undefined, but I imagine in a PUT/POST body does indeed make the
most sense.
Using the Link header in a request doesn't have well-defined
semantics.
I wonder then whether it's not sensible to define these semantics in
an[other] Internet Draft (ala Set-Cookie) rather than having everyone
running off and inventing their own in-band solutions... doing so
would make
for some really clever RESTful interfaces.
Sam
Offline 
Send Email
