Sam Johnston a écrit :

> Does this not strike you as far more complicated than necessary? Under
> your proposal I need to do a bunch of requests and understand a new
> language just to work out that two resources are related.

Indeed, this is a little overhead since here I modeled a one-to-many (or
many-to-many as suggested before) relationship, and added more semantic
than necessary here for example, implying the use of RDF, which is IMO
the better approach to represent metadata for and links between
resources. A more simple approach could use text/uri-list [RFC2483] as
media type for the representation of the resource containing the
relations (i.e. a simple uri...) as in

===============
GET /buildings/1234
Accept: image/jpeg
----------
200 OK
...
(jpeg representation of the building)
==============
GET /buildings/1234
Accept: text/uri-list

200 Ok
...

http://www.example.com/architects/spamegg
==============

granted that it is a one-to-one relation and there is no ambiguity on
the link semantic (as with Link header).

The main point is that the link is itself a (sub)resource (or an
alternate representation) of the initial resource and can therefore be
manipulated directly using existing methods

=============
PUT /buildings/1234
Content-Type: text/uri-list

http://www.example.com/architects/foobar
=============

> The Link: header accomplishes the same job in a far simpler and more
> performant manner, only until now no mechanism (beyond the HTTP LINK and
> UNLINK verbs) has been specified for creating them.

> Therein lies the question... what is the most intuitive way to associate
> resources? Given the relationships are exposed via HTTP headers one
> would assume that the same mechanism could/should be used to manage them.

As stated in Roy thesis (if I'm right), every piece of information that
can or should be manipulated by the UA must be a resource by itself.

Moreover, this approach allow many-to-many relations (not talking about
several kinds of semantic relations) to be represented and manipulated
in the same homogeneous way as simple non ambiguous unique links


> On Wed, Jul 1, 2009 at 11:48 AM, Yannick Loiseau <yloiseau@...
> <mailto:yloiseau@...>> wrote:
>
>
>
> I agree with mike.
> IMHO, it seems it is here a meta level problem w.r.t. the application
> vs. protocol POV.
> Taking the building/architect example, the architect of a building is a
> metadata for the application (information about the building). But as
> long as the UA needs to manage this information (read/edit), it should
> be a resource by itself, i.e. data at the protocol level. The fact that
> this metadata can't be embed in one of the representations of the
> building resource (e.g. an image) just imply the need for another
> representation (conneg is your friend), not that this information
> pertains to HTTP headers. RDF was just design for this use case:
> provide
> external metadata about resources that can't embed them. Turtle or N3
> can be used for xml reticents, or just a custom key:value format (but
> don't reinvent the wheel :)
> Metadata being a resource, they can be easily edited (using POST, PUT,
> PATCH, or lower granularity (sub)resource manipulation).
>
> example (turtle not tested)
> ==============
> GET /buildings/1234
> Accept: image/jpeg
> ----------
> 200 OK
> ...
> (jpeg representation of the building)
> ==============
> GET /buildings/1234
> Accept: text/turtle
> ---------
> 200 Ok
> ...
>
> @prefix rel: <http://www.example.com/relations/ns#> .
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
> @prefix ent: <http://www.example.com/entities/ns#> .
>
> <http://www.example.com/buildings/1234>
> a ent:building ;
> dc:title "A nice building";
> rel:architects <http://www.example.com/buildings/1234/architects;
> ==============
> GET /buildings/1234/architects
> Accept: text/turtle
> ----
> 200 Ok
>
> @prefix ent: <http://www.example.com/entities/ns#> .
>
> <http://www.example.com/buildings/1234>
> ent:Architect <http://www.example.com/architects/spamegg> .
>
> ==============
> POST /buildings/1234/architects
> ...
>
> http://www.example.com/architects/foobar
> -------
> 201 Created
> ...
>
> @prefix ent: <http://www.example.com/entities/ns#> .
>
> <http://www.example.com/buildings/1234>
> ent:Architect <http://www.example.com/architects/foobar>,
> <http://www.example.com/architects/spamegg> .
> ===============
> GET /architects/foobar
> Accept: text/turtle
> ------
> 200 Ok
>
> @prefix ent: <http://www.example.com/entities/ns#> .
> @prefix rel: <http://www.example.com/relations/ns#> .
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> <http://www.example.com/architects/foobar>
> a foaf:Person ;
> foaf:name "Foo Bar";
> rel:hasBuilt [
> <http://www.example.com/buildings/1234> ;
> <http://www.example.com/buildings/5678> ;
> ] .
>
> If the list of buildings for an architect needs to be manipulated, the
> same pattern can be used, creating a /architects/foobar/buildings
> resource, using HATEOAS...
>
>
>
> >
> > FWIW, Link *Headers* make sense to me when the link are metadata
> about
> > the resource. However, when the links are to be treated as
> first-class
> > resources themselves, I think Link Headers is not the right
> choice. For
> > example, I assert that links appearing in the <head /> section of
> > typical HTML documents are metadata. Links that appear in the
> <body />
> > section are not.
> >
> > I am not privy to the details of your particular use of links,
> but I get
> > the impression that they are more than metadata. If true, I would
> > consider placing the links either in the body of the resource or,
> when
> > the resource does not support body links easily (certain binary
> files,
> > etc.), I would add a single link header (Link:
> > <http://www.example.org/resource123/links>; rel=related) that
> points to
> > the related resource that holds all the links. One possible
> advantage of
> > this approach is that the related links are now exposed in a way
> that
> > easily allows searching and filtering using well-established
> mechanisms.
> >
> > Also, this sentence from your last post caught my eye:
> > <snip>
> > It's unavoidable (I think) that a case in which you might simply
> add a
> > foreign key or a bridge table when thinking relationally, you
> need to do
> > lots of contortions to do RESTfully.
> > </snip>
> >
> > This is very true. For me, that's an excellent reminder that the
> > relational approach is not the same as a RESTful approach.
> >
> > mca
> > http://amundsen.com/blog/
> >
> >
>