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

Bill Burke bburke at redhat.com
Sat Apr 17 15:01:09 UTC 2010



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




More information about the rest-practices mailing list