JBoss has formally announced a new REST-* initiative during JBoss World at the beginning of the month.
REST-* is trying to clearly separate itself from WS-* by pointing the following differentiators:
WS-* is an excellent set of specifications defining various protocols and envelope formats for implementing middleware services over a network. While a vast improvement over CORBA it does suffer from a few disadvantages that the REST-* community hopes to fix, mainly:
WS-* doesn't leverage HTTP WS-* uses HTTP as a transport protocol. WS-* services mainly use HTTP as a connection setup mechanism and ignore the rich and proven features that make the Web so successful... Because we are focusing on RESTful principles the specifications put out by this organization will fully leverage the HTTP protocol and not try to re-invent its technology
WS-* has a high barrier to entry The WS-* stack is hard to implement and requires a complex stack on both the client and server to use... We hope to minimize the barrier to entry in our suite of specifications.
WS-* requires an envelope format The WS-* stack requires SOAP, an envelope format for WS-* sent message... The HTTP message format is good enough. It is simple, robust, and flexible enough.
The architectural goals of this initiative 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...
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.
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... Specifications should cover 80% of the most common use cases. Edge cases should not be in the main specifications...
Avoid Envelope formats Whenever possible, avoid envelope formats... Envelope formats encourage tunneling over HTTP instead of leveraging HTTP... 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.
According to the announcement, JBoss is attempting to create a fully collaborative community, similar to JBoss.org, not something driven by vendors for vendors. They are envisioning an open source approach to:
... defining new protocols... but one of the main points about this whole effort is to document guidelines and best practices for doing things in a RESTful manner (both with and without HTTP). That might include security, management, etc.
(By the way, the above quote from Mark Little already contradicts with the architectural goals mentioned before, by hinting to both new protocols and non HTTP support).
According to Mark:
If the only thing we end up being is an aggregator for links to "standard" ways of accomplishing this or that then that's a successful outcome too... this was started: because our community wanted it. They kept running up against the same questions and lack of clear answers from various sources such as books, experts in this space and other resources. In some cases they'd get many different answers. Does that mean the answers don't exist? No. But if people who really understand REST can't agree on something then what hope is there for those who just want to go and use it? That's what REST-* is about: bringing together communities to try to come up with clear guidelines so that there's a place for everyone to go when they need those answers.
Although this new initiative is trying to stay away from REST vs WS debate:
The benefits of REST over WS-* has been debated across many articles, blogs, and public mail lists. We don't want to rehash all of it here. Please do a Google search on "REST vs. WS-*" if you want more information.
It effectively does so, by making some (not completely founded) references to WS* features. For example, it tries to say that WS* is heavy, while REST is a light-weight. Well, both standards can be implemented "by hand", in which case (assuming HTTP transport) both require about the same amount of code. On another hand, if a runtime support for automatic marshalling/unmarshalling and message routing is used, the amount of code is also about the same (for example, RestEasy - which is a very nice framework - distribution contains 38 jars). If the comparison is done for the same level of abstraction, the amount of required code is about the same. And the list goes on.
So, it comes as no surprise that the REST* announcement caused quite a few replies on Internet. Steve Jones’s post - REST-* can you please grow up - sums it up quite well:
The REST-* effort might end up documenting what already exists which indicates that part of the challenge is that lots of people don't really know what REST is and certainly struggle as they look to build higher class systems and interoperate between organizations. Part of this is of course about up-front contracts and the early vs. late validation questions. But part of it also appears to be pure snobbery and a desire to retain arcane knowledge.
He continues by stating that:
If REST really is some sword of Damocles that can cut through the integration challenges of enterprises and the world then what is the problem with documenting how it does this and having a few standards that make it much clearer how people should be developing. Most importantly so people (SAP and Oracle for instance) can create REST interfaces in a standardized way that can be simply consumed by other vendors solutions. It can decide whether WADL is required and whether Atom and AtomPub really cover all of the enterprise scenarios or at least all of the ones that count (i.e. lets not have a REST-TX to match the abomination of WS-TX).
Both REST and WS have their place in real life implementations. The issue should be not which one is better, but rather how they can coexist and when is one more appropriate. The other important thing is to make sure that comparisons are based on merits, not beliefs, no matter how strong they are. There are many useful standards and patterns created by WS* and the issue is whether it makes sense to start over or to see how these patterns can be applied to REST.