[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AtomPub Media Repository
Asbjørn,
this is an interesting use case and using AtomPub is a very good idea. Suggestions below.
On Feb 8, 2010, at 9:52 AM, Asbjørn Ulsberg wrote:
> Hi.
>
> In my company, we're in the process of specifying a Media Repository that will serve two purposes:
>
> 1. Work as a media/file repository for all of our web sites
> 2. Serve images transformed (with ImageMagick) according to pre-defined templates
>
> A "template" is simply an XML snippet that describes how an image should be scaled, cropped, etc., to fit a given use on a web site. A typical example is "product thumbnail". I would like to build this system with AtomPub at its core and extend it where necessary. After having an initial planning meeting we have found some possible obstacles:
>
> When POSTing a new image to the repository, it would be wasteful to transform the image to any available transformation template then and there, since we won't know if the image will be used in all available transformations. To preserve disk space, we would like the system to transform images only when a GET is performed on an URI representing a given image transformed through a given template.
>
> When new templates are created, it should be applicable to all existing images without any heavy background services. Just doing a GET on an URI representing an existing image transformed with the new template, should be enough.
All that makes sense.
>
> 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). I assume there are too many possible templates to list links to all available formats explicitly, so you basically have two options here: some kind of form mechanism or URI templates.
Both design options enable the server to instruct the client how to construct the URI that points to a desired format. Both options require some design time agreement on the form or template parameters (that is ok from a REST POV).
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)
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>
What do we need to add?
If we
- 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
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.
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";
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.
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";
[image data]
>
> Letting the client application build the URI makes it very flexible, but it is not a particularly RESTful design and makes the client instead of the server the owner of the URIs.
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.
> I do, however, find it difficult coming up with an alternative design where the server still owns its URIs and where the client can "ask" to get any image transformed with any template regardless of when the image and/or template is created.
>
> We also have a requirement in the system that it should be usable by many simultaneous clients controlled by many different companies that each should have access to their (and not anyone else's) media repositories. Is it problematic to have indefinitely nested collections and workspaces to solve this? This would allow customers to create virtual folders to store images in and such, which of course would be appreciated.
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.
HTH,
Jan
>
> Any and all ideas are warmly welcomed. To summarize:
>
> 1. How do we give the server control of the URI while maintaining a flexible design that allows a client to request any image transformed through any template?
> 2. Is it problematic to nest workspaces and collections to allow several companies with different logins access to their own repository simultaneously?
> 3. Does something like this already exist?
>
> --
> Asbjørn Ulsberg -=|=- asbjorn@xxxxxxxxxx
> «He's a loathsome offensive brute, yet I can't look away»
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen@xxxxxxx
Blog: http://www.nordsc.com/blog/
Work: http://www.nordsc.com/
-----------------------------------