[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AtomPub Media Repository
On Mon, 08 Feb 2010 12:31:27 +0100, Jan Algermissen
<algermissen1971@xxxxxxx> wrote:
Hi, Jan and thank you for your helpful comments.
this is an interesting use case and using AtomPub is a very good idea.
Thanks, I agree! :)
My colleagues are fine with the client "owning" the URI space and doing
requests like:
http://example.com/acme/photos/image_123.jpg?template=123
The client should not make any assumptions about the structure of the
URIs but discover the URIs to use at run time (RESTs hypermedia
constraint).
Yea, I'm a proponent of enforcing the hypermedia constraint. I do need to
find a great alternative, though.
I assume there are too many possible templates to list links to all
available formats explicitly
Yes, that would lead to major overhad on both the server and client.
so you basically have two options here: some kind of form mechanism or
URI templates.
I've thought about URI templates myself, but haven't found a suitable
solution yet.
Let's suppose you have the following:
Collection of images at /the-service/images (POST images here to add to
collection in the usual AtomPub style)
Collection of templates at /the-sercice/templates (POST templates here
to add new templates in the usual AtomPub style)
Yep, that looks reasonable.
The problem to solve is how to send the client the necessary information
to create the format URIs.
Example:
GET /the-service/images/at-the-beach
200 Ok
Content-Type: application/atom+xml
<entry>
<title>At the Beach</title>
<content
src="/the-service/images/at-the-beach/original/at-the-beach.jpg"
type="image/jpg"/>
</entry>
All fine.
- define a link relation http://your.org/specs/rels/conversions and
- define for that link relation a parameter named 'template' and
- define that for the template parameter names of templates must be
provided and
- that in such a way constructed URIs point to the converted images
Sounds reasonable.
then we can send this to the client
GET /the-service/images/at-the-beach
200 Ok
Content-Type: application/atom+xml
<entry>
<title>At the Beach</title>
<x:link-template rel="http://your.org/specs/rels/conversions";
href="/the-service/images/at-the-beach/conversions/{template}"/>
<content
src="/the-service/images/at-the-beach/original/at-the-beach.jpg"
type="image/jpg"/>
</entry>
Assuming the client knows about the template names (from GETs to the
templates collection) it can consruct a URI of the form
/the-service/images/at-the-beach/conversions/Thumbnail
to GET the image converted with the Thumbnail template.
Sweet.
This approach adheres the hypermedia constraint and lets the server
chage the URI pattern in any way it likes. For example, the whole
conversion could be placed on a different machine:
<x:link-template rel="http://your.org/specs/rels/conversions";
Should "http://your.org/specs/rels/conversions"; be resolvable? As
text/html or something else? Could it be the same URI as the template
collection (application/atom+xml; type=feed)?
href="http://conversions.your.org/converter/images/at-the-beach/{template}"/>
Note that we cannot use <atom:link> because the client would not be able
to know that the href contains a template.
Exactly.
We can also include the Link template in responses to GETs on the image
URI directly:
GET /the-service/images/at-the-beach/original/at-the-beach.jpg
Accept: image/jpeg
200 Ok
Content-Type: image/jpeg
Link-Template:
</the-service/images/at-the-beach/conversions/{template}>;rel="http://your.org/specs/rels/conversions";
That's nice.
Having the client specify the URI is not a problem as such, as long as
the client is instructed how to construct the URI. Any HTML GET form
works like this and if HTML supported PUT it would just work the same
way.
Indeed. The only issue I see with the solution you propose, is that to
request an image transformed through a given template, a client needs to
do two requests; one to retrieve the URI template for the image, then one
to the result URI after transforming the URI template.
In a client application that e.g. lists product images, this may cause
some overhead. Perhaps the URI Template could be "hard coded" in the
client at least before all loops happening on a web page, given that the
transformation template for each image is the same? Then the URI Template
could belong to the transformation template instead of the image (i.e.
inverse of what you propose)?
I am certain that all this can be done with AtomPub quite nicely. You;d
probably need one or two extensions, but that should not be a problem.
Adhereing to the hypermedia constraint enables you to even relocate the
repositories across domains to address any future scalability issues.
Indeed, and this is also the plan. We even want it independent of physical
storage, so we can move that out to the "cloud" if we find it necessary.
--
Asbjørn Ulsberg -=|=- asbjorn@xxxxxxxxxx
«He's a loathsome offensive brute, yet I can't look away»