On Jun 30, 2008, at 1:25 PM, Stephan Koops wrote:
> I do not fully understand what you mean, but: You CAN'T see
> transaction in a REST system, because they are not allowed.
> Transacation requires session state, and session state is not
> allowed in REST. So if you have Tx, you don't have REST, if you
> want to have REST, you coud not have Tx. Or do I miss something?
Umm, session state refers to the meaning of requests being dependent
on the state of prior requests (think FTP commands being relative
to the CWD). The only comparison in HTTP would be if a cookie were
used in the request and the server ignores the method or URI based
on the content of the cookie.
Transactions are another thing entirely -- they are a deliberate
decision by the server to separate the client's actions in a parallel
universe of resources until some commit action is made to merge the
universes. They can easily be done in a RESTful manner without any
changes to the protocols -- just include a commit button that has
the effect of making the private resource set public.
Transactions are not typically used in RESTful systems, aside
from the simple type of preview/commit changes in wiki edits,
because they don't provide any benefit. Outside of some rather bad
textbooks and some very fragile internal systems, transactions
are avoided in practice by real distributed systems because it is
far simpler and more reliable to design the interaction such
that transactions aren't necessary. For example, by building a
contract on the client that doesn't rely on server state and
posting the final contract for approval, or using separate
staging servers or publish toggles for content management, or
by using journaled deltas rather than global state, etc.
....Roy