Comments on: RESTful Leaky Abstractions

By: Semantics are not always ‘mere’ semantics « kalountos ta ma onta

Sat, 16 Apr 2011 04:55:20 +0000

[...] It’s clear that creating proper RESTful transaction semantics is a tricky problem. [...]

By: subbu

subbu — Sat, 05 Sep 2009 17:18:22 +0000

Bill – there is nothing wrong in a compensation engine as long as it is hidden behind a resource. Letting clients know about a “compensation engine” is a leaky abstraction. Clients should see application specific concepts like “canceling an order” but not “run a compensating transaction”.

If you are building products, build an engine for compensation, but let app developers wrap such an engine with resources.

By: Bill Burke

Bill Burke — Tue, 01 Sep 2009 03:30:31 +0000

Well, there’s different types of transactions…I don’t see why a compensation engine wouldn’t be restful as all you’re really doing is coordinating work.

By: John Calcote

John Calcote — Mon, 10 Aug 2009 17:39:53 +0000

Yes, I’ve since concluded this myself. I think the general consensus among the purist RESTful web service community is that there’s no such thing as a general purpose RESTful transaction service. Rather, REST seems to promote the exposure of the highest level services provides by a web service. I actually tend to find this more palatable anyway. :)

By: Subbu Allamaraju

Subbu Allamaraju — Fri, 07 Aug 2009 16:25:43 +0000

The web is not about data rendering. This is an unfortunate consequence of some trying to equate CRUD with HTTP. Check some of the Roy Fielding’s posts on this topic. I

The key point here is that, the server understands the semantics of what a transaction means, and there is no need to expose these semantics to clients.

The best way to solve problems like this is to submit a request to the server to do the transfer. In the real world, a bank transfer does not just mean (Acct1 – sum) and (Acct2 + sum). This may involve several back-end processes, and a client should not be able to control those directly.

HTTP servers are, afterall, servers in distributed apps. So, the same principles of loose coupling and separation concerns do apply.

By: John Calcote

John Calcote — Fri, 07 Aug 2009 16:19:36 +0000

That’s a nice, but useless sentiment. The world is all about using http for web services these days. Bank account management is only one of an entire category of web services that people are trying to implement on the programmable web. I will agree with you on one point, however. The web *is* about data rendering. And an atomic transaction on one or more accounts is a bit of data that benefits greatly from proper rendering – that is from proper REpresentational State Transfer. But what you’re implying is that a bank account web service should be limited to merely displaying these transactions – if a customer wants to actually create them, he has to use another mechanism, such as walking down to the bank. This limitation doesn’t work in the real world, does it?