Re: Do we need transaction support in LDP?

hello ashok.

On 2013-05-09 6:43 , "Ashok Malhotra" <ashok.malhotra@oracle.com> wrote:
>Do we need transaction support in LDP?  One of the big features of LDP
>wrt to the
>rest of the Web is that it is read/write.  If clients can update
>information then we need
>to say something about transaction support.   This could be along the
>lines of the note
>on Access Control.

two brief comments from the loooooong history of debates around
transactions and REST:

- one popular opinion is that if you look at transactions for your REST
service, you have a design-level granularity problem. this means that if
you want to create a scope that extents beyond a single interaction, then
your interaction granularity is too small, and you should design
representations that represent that bigger scope, so that you can handle
everything in just one interaction. (in the popular shopping example, this
translates to the client handling all shopping cart contents as
application state, and then submitting the complete shopping cart contents
in one request when checking out.)

- if you really want/need transactions (but as #1 says, you probably
shouldn't), then design transaction resources and interact with those.
this is doable but gets tricky very quickly, in particular because you
might still have to deal with nasty distributed transactions once the
client follows the "commit" link on the transaction resource. if you're
interested in this design pattern, cesare pautasso has published a couple
of good overview papers. (in the popular shopping example, this is a
server-maintained shopping cart with all the nasty scenarios of abandoned
shopping carts, and shopping carts containing goods from various stores
that all have to go through one checkout lane.)

cheers,

dret.

Received on Thursday, 9 May 2013 19:04:38 UTC