REST-*: Blessing or Bane?

Integration
, , , ,

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