Representational State Transfer is a little like Capability Maturity Model: three big words strung together impressively, but what does the phrease mean? Best way to find out is to agree on how it's parsed. There seem to be two dominant interpretations for REST. (The CMM is beyond scope, but if you want to know how to parse it, just ask.) (KL)
In 'representational state transfer', something gets transferred. Is it state, or is it representation? If it's state, is it the state of a resource or the state of a client? Does 'transfer' mean to change something in place to a different form or value, or does it mean to move something from place to place? (KM)
One interpretation of 'state transfer' is that client state 'transfers' as the result of exchanging resource representations with a web service. For instance, a purchasing client is said to transfer from state to state through the submitting of a purchase order. In this case, 'transfer' really means state 'transition'. I wonder if that was the original intent in the coinage of the phrase. (KN)
Another interpretation of 'state transfer' is again a 'transition', but this time it's the transition of resource state, not client state. In this interpretation, a resource changes state as the result of having state information (and just what constitutes state information can be a deep topic of discussion, in particular whether it implies that end state is explicit or not) transferred from one place in a network to another. For instance, a client submits a new representation of resource state, which gets applied to the resource according to its rules of integrity, resulting in a state change visible to other clients. The other half of this interpretation is that a client may learn of the current state of a resource by requesting a transfer of a representation its state. (KO)
Does the term "representational state" have meaning? Or does "representational" really modify "transfer", as in "the representational transfer of [resource] state"? (KP)
I am also still learning, but my interpretation is "the transfer of a representation of the state of a resource". GET transfers a representation of the current state of a resource. PUT transfers a representation of a new state of a resource. POST transfers a representation of the state of a subresource or related resource or a request to change part of a resource, although POST is obviously the fuzziest case.-- BobHaugen (KR)
POST is the locus of all my concern in this, by the way. When using POST to build composite resources (the container pattern), the body of the POST contains legitimate resource (or soon-to-become-resource) state. But when modifying a simple resource through POST, the POST body tends to be something more like a transaction -- i.e., not really resource state at all, but more like processing instructions. Although instructions seem stateful, because they have bits afterall, they are merely 'nounifications' of actions. The conclusion is that simple-resource POSTing is a flavor of RPC, in which the requested action is some how encoded in the body of the POST. You can obfuscate that encoding, but I don't see how it serves any interest except that of shallow REST zealots (of which there are none!). Help me further along, here... -- WaldenMathews (KS)