--- In [email protected], "Anne Thomas Manes" <[EMAIL PROTECTED]> wrote: > > Correct, Mark. These are principles, not constraints. > > SOA operates at a higher level than REST. (My apologies to Rob.) SOA > defines principles that should be applied when determining what to > build. It doesn't give you very much advice as to how to build it. > REST defines constraints that should be applied when determining how > to build it.
You guessed correctly that I would disagree! :-) REST defines constraints about the interaction between components. 1. Client/server interaction (which SO already specifies in describing consumer and provider) 2. Interaction must be stateless 3. Response must be labelled as cacheable/non-cacheable 4. Uniform interface 5. Multiple layers 6. Code on demand Of these, 3 and 6 are the only implementation level constraints. The others constrain an architect in how to describe architectural components and their relationships. Why REST gets tagged as an implementation detail is because it is invariably tied to HTTP and the Web--because Fielding basically said "Let's extract the architectural principles of the Web." But REST does not prescribe the use of URIs. Nor of HTTP. It's just that those are the most obvious implementation choices. Of course, I may be off base. If so, I'm sure someone will set me straight. :-) -Rob
