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

[Eoghan Glynn]

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.

Cheers,
Eoghan

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

>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rest-practices/attachments/20100417/d3474763/attachment.htm>