RE: Proposed text for section 1.6.2 and 1.6.3

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Wednesday, May 07, 2003 6:05 PM
> To: Champion, Mike; www-ws-arch@w3.org
> Subject: Re: Proposed text for section 1.6.2 and 1.6.3
> 
> 
>
> 
> When, as a client, I do something that results in the server
> sending me a new representation, and when that representation
> includes the identifiers for the next set of relevant resources
> in the domain of discourse for the application, then moving to
> the next state is as easy as following the link.  (Again with some
> complexity elided.)

Yow, you're probably right.  But this is getting too deep for me .... I
think I'd be inclined to just take out the "engine of application state"
stuff and try to keep it at the kindergarten level with my "ordering a book
in a restful and non-restful way."  Actually Dave O. is working on a travel
example something like this for the usage scenarios ... maybe that's where
it all belongs.  

But I'm still looking for help trying to distill out the essence of the
difference in architectural styles between the "API SOA" and "REST SOA"
approaches.  Maybe it's just that in REST architectures, the client
application maintains its state, and in non-REST architectures the state is
generally encapsulated in server-side objects.  But that doesn't ring true
... and I don't buy the alternative that the "API SOA" is the "null style"
where everything goes.  

We may be going down the well-known rathole ... I'll probably make some
quick edits reflecting this discussion, ask the editors to put it in the
draft, and put a big warning that it does not reflect consensus around it.

Received on Wednesday, 7 May 2003 19:40:13 UTC