xasima wrote:
Jerome Louvel <contact <at> noelios.com> writes:
Hi there,If you don't want to add those to the XML representation/document,
you can create a subordinate resource to will handle those
metadata./path/document/345 -> URI of the document resource
/path/document/345/about -> URI of the metadata about the parent documentBest
regards,Jerome
Or / and use the custom headers, doesn't it?
I think it depends on what you call "metadata". Indeed, some data may be
metadata with respect to a given document, but be "core" data from
another point of view. This is why it could be modelled under its own
resource, as Jerome said.
I don't think putting a lot of custom headers sounds like the right
thing to do. Perhaps you could have a custom header that points to your
metadata, for example:
(Request)
GET /path/document/345 HTTP/1.1
Host: example.org
(Response)
HTTP/1.1 200 OK
Date: Thu, 08 Nov 2007 17:06:05 GMT
Server: Noelios-Restlet-Engine/1.0.5
Content-Type: application/xml
X-Metadata-Location: http://example.org/path/document/345/about
Then, you would get the metadata from this other URI.
You could also imagine some sort of version system if you need strict
consistency in case of concurrent access. Let's suppose the metadata
contains the title of the document.
One of the problems you may encounter would be:
1. Client A gets /path/document/345 (and reads from the header where to
get the metadata from (but doesn't do it yet): /path/document/345/about)
2. Client B modifies /path/document/345 and this changes the title, thus
affects /path/document/345/about.
3. Client A gets /path/document/345/about
In this case, the representation client A gets from
/path/document/345/about could be out of sync with the representation
obtained from /path/document/345. Client A may have thus obtained a
document and its metadata which would have two different title valus.
I think one way to solve this would be to keep some sort of version on
the "about" resource, by creating a new resource every time a change
relative to the main document is made.
Thus, if a change to the document affects the metadata, you change the
URI to the metadata you would return by the system. In the same example
as before, this could be:
1. Client A gets /path/document/345 (and knows from the header that the
metadata is at /path/document/345/about/20)
2. Client B modifies /path/document/345, this creates
/path/document/345/about/21 for use in subsequent GETs
3. Client A gets /path/document/345/about/20, which is in sync with the
representation it got during the first step.
You could also have /path/document/345/about redirect to whichever
current version is the latest, but I think it wouldn't really matter,
unless the /path/document/345/about URI meant something in the rest of
the system (in particular, if it was linked from somewhere).
Whether-or-not you need to implement something to deal with such
concurrent queries surely depends on your application and what
concurrency constraints you have. It does not always matter if it's out
of sync, what matters is that your application knows it may be.
Best wishes,
Bruno.
