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):

   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.

Comments

[Maurizio]

+1

I think REST is here also because WS-* has been a total mess. Now somebody from a vendor want to ride the hype again...
First Corba, then J2EE and finally WS-*.

The message is "you don't need to take architectural design decision, just buy our stuff and it will solve your problems". SOA took a bad name exactly because of this kind of messages, now is it the turn of REST?

[Mark Little]

Anne, I think you're missing the point or it's not being explained sufficiently well.

Hopefully the following will help:

http://bill.burkecentral.com/2009/09/16/rest-org-launched/

and

http://blogs.jboss.org/blog/mlittle/?permalink=REST_announcement.txt

[Mark Little]

BTW, as I keep telling you over the years, please don't equate transactions with 2PC :-) If you read the non-2PC protocol that Bill references you'll see what I mean. And as Bill keeps saying (and hopefully he'll post here too) these are simply starting points for discussion. We're hoping you and others will join the community effort, even if it's just to document agreed best practices and guidelines that others in the community can use.

[Bill Burke]

Anne, never said Atom wasn't restful, I just don't think it is appropriate for messaging especially for machine-to-machine communications. HTTP is a fine enough message format.

Also, we're committed to implementing this in an open source way. I think we have a great track record of innovating in the open source community and bringing these innovations to a standards body. REST-* is going to be run like an open source project.

Also, I'm glad people are skeptical. My hope is they keep us honest and keep us on track.

[Bill Burke]

Also, didn't reject RESTMS, I just didn't like their requirement for a envelope format.