- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Wed, 7 May 2003 19:38:06 -0600
- To: michael.mahan@nokia.com, www-ws-arch@w3.org
> -----Original Message----- > From: michael.mahan@nokia.com [mailto:michael.mahan@nokia.com] > Sent: Wednesday, May 07, 2003 9:09 PM > To: www-ws-arch@w3.org > Subject: RE: Proposed text for section 1.6.2 and 1.6.3 > Looks promising! Thanks!! > > 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?" > 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 ? > 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 Wednesday, 7 May 2003 21:38:15 UTC