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

Blogger: Anne Thomas Manes

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

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:

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 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.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview