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

[Bob McWhirter]

> 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" ;)

I dunno if Squid or other http proxies and caches would agree with  
that though. We gotta live within existing deployed http infrastructure.

Bob



>
> > 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
>
> _______________________________________________
> rest-practices mailing list
> rest-practices at redhat.com
> https://www.redhat.com/mailman/listinfo/rest-practices
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rest-practices/attachments/20100417/07048869/attachment.htm>