Re: MUST a collection be returned as an Atom feed?

[Jan Algermissen <algermissen1971@xxxxxxx>]

On Dec 28, 2009, at 7:50 PM, Joe Gregorio wrote:

> On Mon, Dec 28, 2009 at 1:20 PM, Jan Algermissen
> <algermissen1971@xxxxxxx> wrote:
> > On Dec 28, 2009, at 6:44 PM, Joe Gregorio wrote:
> > > Just like when I retrieve an HTML page I know that it might  
> > > contain links
> > > to other resources, but that's as far as my 'knowing' goes. I  
> > > don't 'know'
> > > what the actual URIs are, or even if they are going to be there,  
> > > i.e. it
> > > could be a feed with 0 entries.
> >
> > Yes, agreed.
> >
> > OTH, this is an incidental property of Atom feeds. **Suppose** Atom  
> > feeds
> > had a mandatory link, would you
> >
> > consider the feed format to be bad design   or
> >
> > consider AtomPub bad design because it made returning that feed  
> > format
> > mandatory?
>
> Neither.
>
> Yes, let's presume that an atom:link rel="foo" was a MUST. So what?

Then the client developer would be able to make assumptions about the  
links (state transitions) available after making a certain transition.  
It would know, that after a GET on the collection it will be able to  
follow the foo link.

REST aims at avoiding this kind of coupling[1]; the client must not  
make any design time assumptions about a resource.

OTH, I think that machine to machine clients[2] cannot be coded  
without such assumptions (how would you code anything without assuming  
something about what might possibly be returned by the server in  
response to certain interactions.

If that is true (and I just cannot find an argumentation that it is  
not true) then much more constraining constracts will be in effect in  
machine to machine oriented hypermedia specs than is usually assumed  
for REST style systems. In which case the constracts should be made  
clear and not 'obfuscated'.

(Suppose RFC 5023 would say "Servers MUST at least return application/ 
atom+xml feed documents for GET requests to collections" - I think  
everyone would throw their hands in the air and say: "No, that is too  
much of a constraint" - but effectively RFC 5023 must say something  
like this to make client development possible.)

Jan


[1] Roy calls this "data-oriented equivalent to RPC's functional  
coupling" in
<http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext- 
driven> , assuming I understand him correctly.

[2] "machine to machine clients" meaning clients that do not simply  
process whatever they receive for human consumption (or in some  
crawler-like means).


>   Thanks,
>   -joe

--------------------------------------
Jan Algermissen

Mail: algermissen@xxxxxxx
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------