abdera-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Berry <chriswbe...@gmail.com>
Subject Re: Modeling Media Versions
Date Mon, 08 Oct 2007 21:33:38 GMT
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 <dan.diephouse@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




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message