Loading ...
Sorry, an error occurred while loading the content.

5081Re: transactions with REST

Expand Messages
  • Bob Haugen
    Jun 4, 2005
    • 0 Attachment
      Please forgive me if you eventually get two copies of this message.
      The first one appears to have gone off into space.

      I think it is possible to do transactions RESTfully. Or at least
      something a lot like transactions.

      If you abstract the idea or pattern of a transaction protocol away
      from the details of database implementations, they get easier. In
      particular, 2-phase outcomes no longer require holding locks for the
      duration of the "transaction". Nor does the server need to keep track
      of the state of the transaction.

      For example, see
      http://www.oasis-open.org/committees/download.php/9836/business_transaction-btp-1.1-spec-wd-04.pdf

      One way to deal with transactions RESTfully is to PUT or POST the
      first phase result in a provisional state, and the second phase final.
      In other words, the resource state is the transaction state.

      For a business example, a quote is a provisional state, an order is final.

      Another aspect of transactions from a RESTful point of view is that
      the actual transaction protocol involves only two components at a
      time, one client which acts as the transaction coordinator, and one
      server which acts as the transaction participant or resource manager.

      The client may also coordinate other participants in the same logical
      transaction, but only needs to interact with one at a time, and none
      of the resources need to interact with or know about each other. All
      distributed state management can be done by the client/coordinator.

      I don't know if a transaction tree would be RESTful - where a
      server/resource manager/participant is also a sub-coordinator. But in
      fact that is what happens when Amazon authorizes your credit with
      Visa. In this case, the credit authorization is the provisional
      state, and the drawdown is the final state.

      You could also use compensations, where the provisional state is the
      same as the final state, and you undo the action if the transaction
      aborts, but compensation often doesn't work.

      See also http://www.choreology.com/standards/standards_btm_spectrum.htm
      - it's written in terms of Web service transactions, but the
      provisional-final and do-compensate patterns will work for REST, too.
    • Show all 19 messages in this topic