[rest-practices] Atom as a generic container? [was Re: Media types]

[Bill Burke]

Eoghan Glynn wrote:
> 
>  > On one hand maybe somebody wants to listen for updates to VMS.
>  >
>  > On the other hand, I don't see the point of using Atom for returning 
> collections.  It was written as a format for feeds not a collection format.
> 
> 
> Hi Bill,
> 
> So just to clarify, the original idea wasn't so much to wrap the VMs 
> collection in an Atom feed, but rather to use a feed to allow clients, 
> having previously executed a query over the VM collection, to receive 
> lightweight notifications of changes to the set of known VMs and their 
> status. For example a new VM appears, the status of another VM changes, 
> a third VM goes away, etc.
> 
> This would allow clients to update their previous result set, without 
> necessarily re-issueing the original query. It would of course depend on 
> the feed being filtered on the client-side according the original query 
> constraints.
> 
> To ensure that only genuinely fresh updates were received, idea was to 
> use delta encoding with the cleint setting the "A-IM: feed" header so 
> that it recieves only those entries that were updated later than the 
> If-Modified-Since header (set to the timestamp of the original query or 
> the last GET on the Atom feed, which-ever is the later). It was an open 
> question whether the RESTeasy Atom provider supported delta encoding in 
> this way. I'll need to check this out, unless you know off the top of 
> your head?
> 

Resteasy's atom support is just a bunch of JAXB classes.  The Content 
class has a bit more logic in that it allows you to extract 
application-specific JAXB content.  That's it.

If a content handler was written for this delta type you're talking 
about, then I could probably easily modify the lightweight Atom classes 
in RESTEasy to extract the object you're interested in.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com