Subject: [drinks] Discussions on transactions in REST

From: Dean Willis <[email-masked]>
Date: Thu, 15 Sep 2011 09:47:24 -0500

http://stackoverflow.com/questions/147207/transactions-in-rest

The question is whether really need multiple - operation transactions.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 15 Sep 2011 11:34:52 -0400

So you're suggesting that we drop this very useful feature from the requirements and from the protocol, just because classic ReST, which is not even the preferred API technology for SPPP, does not cleanly support it?  That would again be the tail wagging the dog.

This use case, among others, is one that is well known to not work well with classic ReST, and is a symptom of the fact that HTTP verbs and response codes were not designed to be (or to be part of) some all-purpose application-level API.  Many application APIs can be forced to fit into the classic ReST model, but not all of them fit in cleanly.  But the fact that your application does not fit cleanly into classic ReST certainly does not mean that you should start removing nice and necessary features from your application.

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Thursday, September 15, 2011 10:47 AM
To: [email-masked]
Subject: [drinks] Discussions on transactions in REST

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Dean Willis <[email-masked]>
Date: Fri, 16 Sep 2011 10:58:57 -0500

On 9/15/11 10:34 AM, Cartwright, Ken wrote:
> So you’re suggesting that we drop this very useful feature from the
> requirements and from the protocol, just because classic ReST, which is
> not even the preferred API technology for SPPP, does not cleanly support
> it? That would again be the tail wagging the dog.
>
> This use case, among others, is one that is well known to not work well
> with classic ReST, and is a symptom of the fact that HTTP verbs and
> response codes were not designed to be (or to be part of) some
> all-purpose application-level API. Many application APIs can be forced
> to fit into the classic ReST model, but not all of them fit in cleanly.
> But the fact that your application does not fit cleanly into classic
> ReST certainly does not mean that you should start removing nice and
> necessary features from your application.

I'm not suggesting that we drop multi-operation transactions, just 
saying that if we believe we require them in all implementation 
protocols (and we seem to), then we need a "proof of existence" for 
mapping them onto other implementation protocols besides SOAP.

The approach we seem to be taking is to define SPPP as an "abstract 
protocol" that can be realized on any number of "implementation 
protocols". There were two sorts of decisions made in the original SPPP 
design that limited the set of "implementation protocols".

1) The SPPP abstract protocol document was too prescriptive in terms of 
key structure, response codes, etc. You and Syed are fixing this now, 
moving much of the structure from the abstract protocol document to the 
SOAP implementation protocol document. This is very cool.

2) As you point out, the rich transaction functionality of abstract SPPP 
MAY appear to make it difficult to map abstract SPPP onto some 
implementation protocols like RESTful HTTP.

Much of this perceived difficulty goes away if one accepts the premise 
that the mapping between the abstract SPPP protocol and any given 
implementation protocol does not necessarily have to be one-to-one. For 
example, the "verbs" of SPPP do not have to be mapped directly to the 
verbs of an implementation protocol. Nor does one SPPP request have to 
be mapped to exactly one operation in an implementation protocol. It is 
the OVERALL FUNCTIONALITY that has to be mapped.

IMPORTANT CONCLUSION AND GUIDING PRINCIPLES FOLLOW!

In other words, for any given SPPP transaction, the effect on the 
underlying data store MUST be the same, independently of which 
implementation protocol the SPPP transaction used, and also 
independently of whether that SPPP transaction used one operation at the 
implementation protocol, or one hundred operations. It's the result that 
counts.

Take for example multi-operation transactions in SPPP: It is apparent 
that they can be mapped onto RESTful HTTP using the design pattern given 
in the web-thread I referenced earlier in this discussion. The fact that 
this introduces a new implementation-specific "transaction" object" and 
that multiple RESTful operations on this transaction object are used to 
produce the results of an SPPP multi-operation transaction is irrelevant 
to either abstract SPPP or to the SPPP-SOAP binding.

We've shown that abstract SPPP, including multi-operation transactions, 
can be implemented in a sufficiently RESTful manner that at least some 
significant subset of REST advocates wouldn't claim is totally broken, 
and that other REST advocates would say is merely an existence proof 
that it's possible to implement the functionality using their definition 
of proper "REST".

This is a very good thing -- I believe it's good enough that we will be 
able to use it to prove to the IESG that the restructured documents pass 
the REST-test.

If I were building a RESTful API for SPPP, I'd probably do one entry 
point for each of the primitive data types (route groups, destination 
groups, etc.), a set of entry points for offers, accepts, and a separate 
"transaction" entry point set for doing multi-operation transactions 
that require a commit/rollback semantic. There are probably other ways 
to do it, but the fact that even a lightweight like me BELIEVES it can 
be done in a straightforward manner indicates that we're headed in the 
right direction.

--
Dean