RE: Proposed text for section 1.6.2 and 1.6.3

Could we keep it simple and reduces it to bullets. Maybe that will keep it 
less metaphyical. Here's my cut:

REST describes a system where 
1. representations of resources are transfered
2. uniform (a set few) state change requests are identified by the client
3. resources are all addressable/reachable
4. the server does not maintain state
5. resource representations may contain other resource identifiers 
   useful for the client to explore the application search space. (my
   parsing of the Walden/MikeC exchanges)

'API SOA' describes a system where
1. representations of resources and/or state changes are transfered  
2. not all resources are addressable/reachable, services can hide/encapsulate 
   resources
3. the server may maintain state


MikeM


>-----Original Message-----
>From: ext Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
>Sent: May 07, 2003 07:40 PM
>To: www-ws-arch@w3.org
>Subject: 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 21:10:12 UTC