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

[Jan Algermissen <algermissen1971@xxxxxxx>]

On Jan 3, 2010, at 8:22 PM, Roy T. Fielding wrote:

> On Jan 3, 2010, at 6:12 AM, Jan Algermissen wrote:
> > I think I see where we disagree or misunderstand each other: In my  
> > understanding, it is part of the semantics of application/atomsrv 
> > +xml that a service that sends that media type to describe itself  
> > constrains itself ('promises') to conform to RFC 5023. In our  
> > example, it promises to return an Atom feed upon a GET request to a  
> > collection.
>
> Atom is a protocol written by a committee to lay out a set of choices
> that they deem will be interoperable in practice.  It contains many
> such over-specifications. Just ignore them.  The media type cannot  
> bind
> a service to do anything -- it only serves as a guide for  
> interpretation
> of the current state.

Yes, of course. The hypermedia constraint requires the client to make  
no design time assumption but discover at runtime.

What I am having trouble with is that some design time contract is  
necessary to enable implementations of machine clients for services  
(e.g. AtomPub services or Online Stores, Auctions,...). Clients that  
are effectively human driven do not need that, common sense is enough  
to buy a book at Amazon.

But building a machine client for Amazon requires a design time  
specification of what to expect - how would you tell someone to  
implement such a client (without looking at a/the service *instance*)?

A machine client would (in my view of the world anyway) be implemented  
to go and perform some ordering (follow a certain goal/intent) and not  
be implemented to place an order should it happen to come across a  
state that as a 'place order' transition.

In a rant-tone one might say that REST's amount of loose coupling is  
an illusion if the human mind (or some form of AI) is removed from the  
runtime.

(Please note that I am not implying that anyone claimed that that form  
of loose coupling is actually possible nor intended by REST).

Jan

P.S. And again sorry for hammering on this - I am just wondering  
whether I an completely dumb or what part of the picture I am missing.


> One of the ways to interpret that state is to follow the links within
> it with some degree of expectation.  If that expectation fails to be  
> true,
> then what are you going to do about it?  Are you going to halt and  
> wait for
> the service to be compliant with some external spec?  Or are you  
> going to
> interpret that next state independent of the former state?  Those are
> application-specific choices, and it doesn't matter to Atom which one
> you take.  Unfortunately, it did matter to the committee, so there  
> is an
> unnecessary requirement in the spec in order to pretend that such a  
> case
> will not occur in practice.  And maybe it won't.
>
> ....Roy

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

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