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

[Eoghan Glynn]

> 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?

Cheers,
Eoghan


On 16 April 2010 20:53, Bill Burke <bburke at redhat.com> wrote:

>
>
> Bryan Kearney wrote:
>
>> Eoghan suggested something similar here:
>>>
>>>   https://fedorahosted.org/pipermail/rhevm-api/2010-April/000025.html
>>>
>>>  application/atom+xml
>>>>
>>>
>>> This would just be e.g.:
>>>
>>>   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>>   <atom:feed xmlns:atom="http://www.w3.org/2005/Atom">
>>>     <atom:title>VMs feed</atom:title>
>>>     <atom:updated>2010-04-16T09:47:55.288+01:00</atom:updated>
>>>     <atom:id>http://{host}/vms</atom:id>
>>>     <atom:author>
>>>       <atom:name>RHEV-M</atom:name>
>>>     </atom:author>
>>>     <atom:entry>
>>>       <atom:title>vm2</atom:title>
>>>       <atom:content>
>>>         <vm>
>>>           <link rel="self" href="http://{host}/vms/3"/>
>>>           <id>3</id>
>>>           <name>vm3</name>
>>>           <actions>
>>>             ...
>>>           </actions>
>>>         </vm>
>>>       </atom:content>
>>>
>>> That's simple enough:
>>>
>>>
>>> http://git.fedoraproject.org/git/?p=rhevm-api.git;a=commitdiff;h=3fff835a
>>>
>>> But now, what about supporting clients who prefer json or yaml? Does
>>> "application/atom+json" make much sense, I wonder?
>>>
>>>  application/atomcat+xml
>>>>
>>>
>>> We'd use this to describe e.g. 'vm' and 'host' categories?
>>>
>>
>> So... one of he items I heard about why REST and not SOAP is that the SOAP
>> envelope is terrible. What I see here is starting to look like such an
>> envelope. Will you be supporting "natrual" xml and json as well?
>>
>>
> 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.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> rest-practices mailing list
> rest-practices at redhat.com
> https://www.redhat.com/mailman/listinfo/rest-practices
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rest-practices/attachments/20100416/2302ebad/attachment.htm>