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

Eoghan Glynn eoghan.glynn at gmail.com
Sat Apr 17 17:02:33 UTC 2010


> That's an even better reason why this isn't a good idea.  You'd never be
able to
> effectively insert a cache if you had special semantics tied to
if-modified-since.

OK, thanks Bob & Bill for the clarification, it now fairly clear that the
delta encoding route is not the way to go.

> Are you interested in always getting the latest view of the VM
collection?
> Or are you interested in each change event that happened to the
collection?

Yes and yes ;)

The idea was to get an initial collection of VMs satisfying certain
criteria, but then to also retrieve updates as the status of the VM
collection changes, without necessarily re-evaluating the entire query.

So I'm thinking now of a simpler alternative approach that uses neither
If-Modified-Since nor Atom (as the conduit to push out updates). I'll flesh
these ideas out on Monday and do some prototyping.

Cheers,
Eoghan


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

>
>
> Eoghan Glynn wrote:
>
>>
>> Yeah, I take your point Bill, I may have been over-gilding the lily ...
>>
>>  > I think what you are suggesting (if I'm understanding right) of using
>> If-Modified-Since
>>  > semantics as a query-like mechanism is overloading the *actual* meaning
>> of this header.
>>  > This header is meant for conditional reads or updates to save bandwidth
>> (read)
>>
>> Yes, there would be a subtle change to the semantics of If-Modified-Since,
>> in the sense of escaping the "all or nothing" straight-jacket.
>>
>> So the idea is to avoid a conditional GET being returned either /nothing/
>> (304 "Not Modified") if not a single entry in the feed has changed, or
>> /everything/ (the entire Feed) even if only a relatively small subset of the
>> entries have been updated.
>>
>> You're absolutely correct that this does go against the letter of the
>> spec, which requires that a non-empty return would be exactly the same as
>> for a normal GET.
>>
>> Though I'd argue that the delta semantics are still kinda within the
>> "spirit of the spec" ;)
>>
>>  > In the REST-* messaging work I did, a "next" link header is provided
>> with each event
>>  > posted to the feed (or topic as is referenced in the spec).  This
>> "next" link points to the
>>  > next *sequenced* event and acts as an index pointing to a specific
>> place in time.
>>
>> This is interesting, maybe we can structure the provision of updates to
>> the VM collection in a similar way. There was a suggestion previously of
>> taking a paginated approach, but I didn't really like the idea that the
>> state of VMs reported in earlier "pages" could have changed by the time the
>> later "pages" are retrieved. But perhaps explicitly treating the "next" link
>> as a pointer to /future/ updates would avoid that sort of messiness.
>>
>>
> I'm not sure what the end goal is here.  Are you interested in always
> getting the latest view of the VM collection?  Or are you interested in each
> change event that happened to the collection?  If its the former, then a
> conditional GET using if-modified-since or if-not-match is the best approach
> even if there are query parameters (I'm pretty sure caches are ok with query
> parameters).  If its the latter, a link approach is better IMO.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rest-practices/attachments/20100417/8042f73e/attachment.htm>


More information about the rest-practices mailing list