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

[Bill Burke]

Eoghan Glynn wrote:
> 
>  > 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.
> 
> 
> Hi Bill,
> 
> I don't think any new type support is needed for the RFC3229+feed idea, 
> rather it would be more a case of just filtering out older entries from 
> the feed, and then marshalling the pruned feed in exactly the same 
> format as before (just with a different status code, 226 "IM Used", and 
> also an extra header IIRC).
> 
> I guess this filtering could be done manually, but we probably wouldn't 
> want to be creating separate new Feed objects for each different 
> If-Modified-Since timestamp that we see.
> 

Sounds pretty complicated to me.  When I hear talk about diff/delta 
formts and the like (especially with PATCH), I think people are 
forgetting about both the implementation of these services and what they 
will be actually doing.  The end goal is not to store data in a document 
file on the server, or to maintain a cache of a document on the client. 
  The end goal is to transform the representation so that it can be 
consumed by business logic of a specific programming language, and 
probably stored in a relational database.  I guess what I'm saying is 
that 'boring' is much easier to maintain and re-use than 'clever'.

Then again, I may not be understanding exactly what you want.

I reread your previous post:

 > 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

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) or to sequence updates 
(optimistic concurrency).  This header is not meant to be used to get 
different representations.

I guess what I'm saying is that I think the actions should be driven by 
hypermedia (links) rather than some overloading of HTTP protocols. 
Which leads me to...

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 "next" link can 
point to a future event. (I'm not sure if Atom  or RFC5005 has this 
concept or not of a future event)

When the client follows the "next" link the server responds with the 
sequenced next representation.  The response contains a new "next" link 
that the client follows to retain the sequence.

I'm not advocating REST-* Messaging, but, instead trying to illustrate 
that hypermedia driven interaction is simpler.  In this case, the link 
itself has all the information needed to drive the 
interaction....And...since its opaque all the client has to know is that 
this link exists, and to follow it (through a simple GET) to get new 
information.

So, in summary, I think you need 2 separate things:

* IMO, keep it simple and define some sort of change-event format that 
is specific to your domain
* Let links be indexes into your event feed instead of overloading the 
semantics of HTTP

Finally, I have no idea if this rant at all answers anything or even 
pertains to what you are talking about.  Apologies if it does not.


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