REST-*: Blessing or Bane?
Recently, JBoss has announced a new architecture initiative called
REST-*. The purpose of this initiative is to create an open source
project dedicated to the goal of applying web architecture to
integration and middleware. They intend to take traditional integration
concepts and find which ones fit into the
The hope is to publish the specifications that will be created from this
From the website, the stated architecture goals are:
- Low barrier to entry - Clients that use the specification should
have a very low barrier to entry. They shouldn’t need to install a
library or large stack of software to use a specification. An HTTP
client or web server provided by the language or platform should be
enough to implement or use implementations of the specification.
- Edge Cases should be Extensions- Edge cases that complicate the
main specification should be defined in a separate
sub-specification. Extensions should strive to be layered on top of
the main specification by using facilities like HATEOAS and HTTP
conneg to provided their features.
- Pragmatic REST - While a specification should strive to follow
RESTful principles, simplicity should never take a back seat to
being a pure RESTafarian. If you need to bend the rules of REST to
create a simpler design, then that’s the path that should be taken.
- 80/20 Rule - Specifications should remain simple. Many times in
specification efforts, edge cases cause a lot of bloat and
complexity within the specificaiton making it difficult to use,
understand, and implement. Specifications should cover 80% of the
most common use cases. Edge cases should not be in the main
specifications. REST should be able to provide the facilities
(HATEOAS, HTTP conneg) to abstract away edge cases.
- Avoid Envelope formats- Whenever possible, avoid envelope
formats. Examples of envelope formats are SOAP and Atom. Envelope
formats encourage tunneling over HTTP instead of leveraging HTTP.
They also require additional complexities on both the client and the
server. In most cases HTTP headers should be enough to transfer
metadata about the request, response, or resource.
- Isolate data formats to extensions- If possible, specifications
should try not to define new data formats.
I will be following the developments of this project very closely since
this is an area where I am dabbling a bit myself. I am very interested
in seeing how they approach some of the issues I have blogged about
recently. My only concern is that they will attempt to build
specifications around some of the worst ideas in distributed computing.
That is my primary complaint with the way the WS-* specifications have
evolved. Back when the “S” in SOAP still stood for “Simple”, SOAP seemed
like a promising way to build distributed systems based on open
standards. Unfortunately, the specification committee promptly took the
opportunity to add everything including the kitchen sink. In the process
they made it nearly impossible to build anything with SOAP-based
services and wrecked the promise of interoperability between different
vendor implementations. I just hope the REST-* project does not repeat
the same mistakes. (Distributed transactions and reliable messaging. I
am looking at you.)