process management service oriented architecture soa blog posts

REST-* (I've got a bad feeling about this)

Blogger: Anne Thomas Manes

643

Thanks to Mark Nottingham (@mnot) for alerting me to the REST-* initiative. He tweeted about it last night (this morning his time):

   REST-*? Well, this will end badly... http://bit.ly/cF6CG.

My sentiments exactly. I'm not sure how I missed it. According to the REST-* website, the effort was launched on July 14. (Bastille Day? How ironic.)

Some other comments from the twitterverse:

@psd: amazed how so many people are taking REST-* seriously. It's a brilliant piece of satire.
@jimwebber: Choo choo! There goes the cluetrain... and REST-* missed it.
@ironick: .@distobj REST-* says avoid envelope formats like... wait for it ... Atom. WTF? When did Atom become anti REST?
@distobj: I think a better name for REST-* would be HTTP-* - makes you wonder why they're not doing it at the IETF
@bobinator: @atmanes REST follows WS, CORBA, DCE, etc. they will never learn

It appears that Bill Burke of Red Hat/JBoss is responsible for REST-*. So what exactly is he planning to do? Well, according to the home page:

While REST has gained huge momentum in the SOA community, there hasn't been a lot of standardization of traditional middleware services. The REST-* community aims to introduce new REST-based standards for these traditional services where none exist and provide well-defined guidelines where protocols do exist.

The effort currently lists two specification projects:

  • REST-* Transactions: REST-* Transactions is a specification that attempts to define a RESTful interface for transactions.   It describes the interaction between coordinator services and transaction participants as well as how transactions can propagate in distributed applications.  It defines both a 2-Phase-Commit model as well as a Forward-Compensation protocol.
  • REST-* Messaging: Messaging encompasses publish and subscribe and point-to-point protocols.  This specification defines a RESTful interface for queues (p2p) and topics (pub/sub).

What really concerns me about this effort is Bill's perspective on REST. As he said in his "What REST has to be" blog post:

I really don’t care in the end if any of the architectural principles of Roy’s thesis are broken as long these requirements [simplicity, low footprint, interoperability, and flexibility] are met.  Pragmatism has to be the most important thing here.  We can’t fall into religious and academic debates on the purity of a distributed interface.

I believe in being pragmatic, but if you don't adhere to the REST principles (everything is a resource with a uniform addressing scheme [i.e., a URL], interactions using representations, uniform methods, stateless interactions, using hypermedia as the engine of state), you won't produce RESTful systems, and you won't attain the desirable RESTful characteristics (scalability, serendipity, network effects, etc) that REST is supposed to enable.

Bill also asserts that AtomPub isn't RESTful because it uses an envelope. This tells me that Bill equates REST with POX rather than with a set of design principles. (i.e., he doesn't get REST.) And he rejects RESTMS (which builds on AtomPub and AMQP) out of hand. His current spec for REST-* Messaging is nothing more than a RESTful facade over JMS. (He says that he plans to publish a new spec next week, though.)

I can see the need for a RESTful push protocol to enable pub/sub. I think RESTMS has some interesting potential. I reject the idea that we must have transaction protocols. A 2PC protocol cannot be stateless. That doesn't mean that you can't manage transactional integrity in REST. It just means that you can't us a 2PC protocol to do it. But there are other ways to ensure transactional integrity.

A more useful effort would be one that defines RESTful patterns that support and enable mission critical capabilities like reliable delivery, transactional integrity, and the like. But please, let's not reinvent CORBA on REST.

Here's hoping the whole REST-* thing just dies out.