RE: Proposed text for section 1.6.2 and 1.6.3

>
>Looks promising!   Thanks!!
>

Great. Simple brains (like mine) require simple statements. 

>> 
>> REST describes a system where 
>> 1. representations of resources are transfered
>> 2. uniform (a set few) state change requests are identified 
>> by the client
>
>I don't understand ... could you rephrase?  Is this the famous "uniform
>interface constraint", i.e. GET/PUT/POST/DELETE are the "state change
>requests?" 

Yes, the HTTP verbs. The point is that only a very limited set of state 
change requests can be made, they can be universally applied to any resource, 
and they can only be expressed by the client. Anyways, I think this is 
distinquishing factor.
 
>
>> 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
>
>Hmm, so the "arguments" to an "API" are "representations of 
>resources"?  I
>remember discussions of that idea a few months ago, but I 
>didn't see much
>sign of consensus on it.  Could this just be rephrased 
>"application-specific
>data is transferred with few constraints on message semantics" 
>or something
>like that ?

The difference I was trying to draw is that REST separates the resource 
REpresentation from the STate change request in the message. API SOA does not. 
API SOA message markup captures both the representation of the resource/service 
and the representation of the state change request. 

As for the parameters issue, perhaps these are service representations or even 
'state change request' representations - rather than resource representations. I 
guess this is how I interpret 'application specific data'. But this is just my 
take on it while trying to stay within the language of representations. 


>
>> 2. not all resources are addressable/reachable, services can 
>> hide/encapsulate    resources
>
>Yes!  This paired with REST #3 seems like a very critical distinction
>
>> 3. the server may maintain state
>
>This too, as others have pointed out.
>
>
>

Received on Thursday, 8 May 2003 00:12:14 UTC