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:
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:
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.
Leave a Comment
You must be logged in to post a comment.
