You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@abdera.apache.org by Dan Diephouse <da...@mulesource.com> on 2007/10/08 19:11:35 UTC
Modeling Media Versions
OK, I have yet another modeling question. Lets say I have an image
library and I want to archive different versions of the image as they
move through the photoshop process. (don't get too caught up on the
example, the basic ideas is that we have an entry which is backed by
media and then its versioned).
The general idea of how to model it makes sense to me now based on the
previous collection modelling thread. I will have a Collection of
images. Each image <entry> will then contain a <collection> which refers
to a specific version.
My question is how do I go about creating the first version? I can see
two ways.
1. Post the media to /images and create an entry at
/images/foo_image/version1
2. Post to /images with just some metadata and create a
/images/foo_image resource. Then post the media to /images/foo_image.
The second one seems more correct, but I dislike how its two steps and
you have to create a resource without the initial image. Is there
anything wrong with doing the first one?
Does that make sense? Any ideas?
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: Modeling Media Versions
Posted by Chris Berry <ch...@gmail.com>.
FYI: there is a very nice, helpful discourse on essentially this
subject in "RESTful Web Services" (by Ruby/Richardson) on pg. 217.
"The expectation is that the URI designates a particular
representation of the resource".
And then a discussion of the representation-specific URIs for a
particular, given resource.
For example; foo/bar/123, foo/bar/123.en.xml, foo/bar/123.es.xml,
foo/bar/123.html, .... may all be different representations of the
Resource foo/bar/123
Cheers,
-- Chris
On Oct 8, 2007, at 4:03 PM, Dan Diephouse wrote:
> I like your solution better and I think I will have to adopt it!
> That would leave me with something like:
>
> /images is where new images are POSTed to
> /images/foo.atom gets entry for latest image. Has a <collection>
> element which points to a feed of previous revisions
> /images/foo gets latest image. a PUT to /images/foo updates the
> latest image and adds a new version.
> /images/foo/feed gets a collection of the revisions
> /images/foo/version gets a particular image version
> /images/foo/version.atom gets a particular version of the entry
>
> Going to have to make some improvements to the CollectionProvider
> stuff (well there's lots of stuff that needs to be done anyway),
> but I think this will work. Thanks a lot Chris.
>
> - Dan
>
> Chris Berry wrote:
>> We are modeling this a bit differently
>> We assume optimistic concurrency, so there is really only a single
>> revision associated with a given Resource (Entry) at any given time
>> e.g. GET /foo/bar/123 ==> always yields the latest/greatest
>> revision of that Entry
>> but to edit an Entry you MUST provide a revision Id -- e.g. /foo/
>> bar/123/2
>> All this info is kept in a metadata database for the Atom "data
>> server "
>> We allow for a "single writer" model by allowing for a "/*"
>> revision (e.g. foo/bar/123/*) and assume that the User knows what
>> they're doing
>>
>> We do all of our creation via PUT, because in our case the Entry
>> identifiers are coming from the outside.
>> But you could do something similar with a POST to the Collection URL
>>
>> What is in the content (and it's storage) is transparent, and
>> implies an implicit contract between you and the User (e.g. we use
>> RelaxNG to impose that contract)
>> Supplying different Representations (foo/bar/123 or foo/bar/
>> 123.jpg) associated with a given Resource seems consistent to me.
>>
>> Cheers,
>> -- Chris
>> On Oct 8, 2007, at 2:46 PM, Dan Diephouse wrote:
>>
>>> Brian Moseley wrote:
>>>> On 10/8/07, Dan Diephouse <da...@mulesource.com> wrote:
>>>>
>>>>
>>>>> Which leads me back to wanting to just POST to /images... Is
>>>>> there anything
>>>>> wrong with just POSTing to /images and having /images/foo,
>>>>> /images/foo/versions, /images/foo/versions/1 and /images/foo/
>>>>> versions/1.jpg
>>>>> all created in that POST?
>>>>>
>>>> Hm, seems fine to me!
>>>>
>>> OK thanks Brian! :-)
>>>
>>> --
>>> Dan Diephouse
>>> MuleSource
>>> http://mulesource.com | http://netzooid.com/blog
>>
>> S'all good --- chriswberry at gmail dot com
>>
>>
>>
>>
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
S'all good --- chriswberry at gmail dot com
Re: Modeling Media Versions
Posted by Dan Diephouse <da...@mulesource.com>.
I like your solution better and I think I will have to adopt it! That
would leave me with something like:
/images is where new images are POSTed to
/images/foo.atom gets entry for latest image. Has a <collection> element
which points to a feed of previous revisions
/images/foo gets latest image. a PUT to /images/foo updates the latest
image and adds a new version.
/images/foo/feed gets a collection of the revisions
/images/foo/version gets a particular image version
/images/foo/version.atom gets a particular version of the entry
Going to have to make some improvements to the CollectionProvider stuff
(well there's lots of stuff that needs to be done anyway), but I think
this will work. Thanks a lot Chris.
- Dan
Chris Berry wrote:
> We are modeling this a bit differently
> We assume optimistic concurrency, so there is really only a single
> revision associated with a given Resource (Entry) at any given time
> e.g. GET /foo/bar/123 ==> always yields the latest/greatest
> revision of that Entry
> but to edit an Entry you MUST provide a revision Id -- e.g.
> /foo/bar/123/2
> All this info is kept in a metadata database for the Atom "data server "
> We allow for a "single writer" model by allowing for a "/*" revision
> (e.g. foo/bar/123/*) and assume that the User knows what they're doing
>
> We do all of our creation via PUT, because in our case the Entry
> identifiers are coming from the outside.
> But you could do something similar with a POST to the Collection URL
>
> What is in the content (and it's storage) is transparent, and implies
> an implicit contract between you and the User (e.g. we use RelaxNG to
> impose that contract)
> Supplying different Representations (foo/bar/123 or foo/bar/123.jpg)
> associated with a given Resource seems consistent to me.
>
> Cheers,
> -- Chris
> On Oct 8, 2007, at 2:46 PM, Dan Diephouse wrote:
>
>> Brian Moseley wrote:
>>> On 10/8/07, Dan Diephouse <da...@mulesource.com> wrote:
>>>
>>>
>>>> Which leads me back to wanting to just POST to /images... Is there
>>>> anything
>>>> wrong with just POSTing to /images and having /images/foo,
>>>> /images/foo/versions, /images/foo/versions/1 and
>>>> /images/foo/versions/1.jpg
>>>> all created in that POST?
>>>>
>>> Hm, seems fine to me!
>>>
>> OK thanks Brian! :-)
>>
>> --
>> Dan Diephouse
>> MuleSource
>> http://mulesource.com | http://netzooid.com/blog
>
> S'all good --- chriswberry at gmail dot com
>
>
>
>
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: Modeling Media Versions
Posted by Chris Berry <ch...@gmail.com>.
We are modeling this a bit differently
We assume optimistic concurrency, so there is really only a single
revision associated with a given Resource (Entry) at any given time
e.g. GET /foo/bar/123 ==> always yields the latest/greatest
revision of that Entry
but to edit an Entry you MUST provide a revision Id -- e.g. /foo/bar/
123/2
All this info is kept in a metadata database for the Atom "data server "
We allow for a "single writer" model by allowing for a "/*" revision
(e.g. foo/bar/123/*) and assume that the User knows what they're doing
We do all of our creation via PUT, because in our case the Entry
identifiers are coming from the outside.
But you could do something similar with a POST to the Collection URL
What is in the content (and it's storage) is transparent, and implies
an implicit contract between you and the User (e.g. we use RelaxNG to
impose that contract)
Supplying different Representations (foo/bar/123 or foo/bar/123.jpg)
associated with a given Resource seems consistent to me.
Cheers,
-- Chris
On Oct 8, 2007, at 2:46 PM, Dan Diephouse wrote:
> Brian Moseley wrote:
>> On 10/8/07, Dan Diephouse <da...@mulesource.com> wrote:
>>
>>
>>> Which leads me back to wanting to just POST to /images... Is
>>> there anything
>>> wrong with just POSTing to /images and having /images/foo,
>>> /images/foo/versions, /images/foo/versions/1 and /images/foo/
>>> versions/1.jpg
>>> all created in that POST?
>>>
>> Hm, seems fine to me!
>>
> OK thanks Brian! :-)
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
S'all good --- chriswberry at gmail dot com
Re: Modeling Media Versions
Posted by Brian Moseley <bc...@osafoundation.org>.
On 10/8/07, Dan Diephouse <da...@mulesource.com> wrote:
> Which leads me back to wanting to just POST to /images... Is there anything
> wrong with just POSTing to /images and having /images/foo,
> /images/foo/versions, /images/foo/versions/1 and /images/foo/versions/1.jpg
> all created in that POST?
Hm, seems fine to me!
Re: Modeling Media Versions
Posted by Brian Moseley <bc...@osafoundation.org>.
On 10/8/07, Dan Diephouse <da...@mulesource.com> wrote:
> The second one seems more correct, but I dislike how its two steps and
> you have to create a resource without the initial image. Is there
> anything wrong with doing the first one?
I think you have more resources than you think you do:
/images - atom:collection
/foo - atom:entry
/versions - atom:collection
/1 - atom:entry
/1.jpg - media
The versions collection really is an independent resource that should
have its on address, which removes the confusing need to POST to an
entry.
I suggest POSTing an entry to /images to create both /images/foo and
/images/foo/versions/, then POSTing to /images/foo/versions/ to create
/images/foo/versions/1 and /images/foo/versions/1.jpg.
Thinking of it like this makes the two step process seem more natural,
IMO. You are creating four resources after all.