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 REST model. The hope is to publish the specifications that will be created from this project as IETF RFCs.
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.)
