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

["Roy T. Fielding" <fielding@xxxxxxxx>]

On Jan 3, 2010, at 12:24 PM, Jan Algermissen wrote:
> 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.

Common sense is just an accumulation of learned protocols.  It only
seems common because we didn't grow up in a jungle wearing skins.

Computers learn common sense slower than we do because computers
have neither taste (feedback) nor hunger (need), and nobody has
figured out how to tell a computer to forget the irrelevant bits
before it runs out of memory.

> 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*)?

Amazon does not have self-descriptive representations intended for
machine clients, though it is possible to find the data if you
learn the patterns (like where ISBNs are used and what they mean).

Nobody said that Amazon is an ideal RESTful interface, or at least
if they did they didn't know what they were talking about.  Amazon
is, in fact, one of the few services that is so big and powerful
and expensive to deploy that it regularly violates REST constraints
in order to drive out competition.  If you happen to be Amazon,
that's a reasonable design goal.  That doesn't prevent Amazon from
taking advantage of REST constraints in other areas, like AWS.

> 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.

What does the machine client want to do?  Mobile agents (or agent crawlers)
are a fairly old topic by CS standards -- older than REST -- and these
questions have been debated for decades.  I think you will find it hard to
replace human intent and decision-making for the big decisions, which is
why the Predator drones are actually guided by human "pilots" (joystick
remote control operators) even though the million little flying decisions
per second are governed by a state machine.  Personally, I'd rather hire
a human than build a self-aware machine.

> 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.

REST is an architectural style for an application.  It does not replace the
need to know what is the application.  What you are looking for is intent,
not coupling, and that is outside the realm of all architectural styles.

....Roy