[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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




> 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 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="">           <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

_______________________________________________


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]