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/
>
>
--
Yannick Loiseau, PhD
Laboratoire LIMOS - UMR 6158
Université Blaise Pascal
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
Offline 
Send Email