Why Are We Different Than WS-*?

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. Some examples are content negotiation and caching.  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.  HTTP is such a ubiquitous protocol.  It should be enough to have a HTTP client library or a web server to interact with enterprise protocols.  We hope to minimize the barrier to entry in our suite of specifications.  We may fail, but it doesn't hurt to try.

WS-* requires an envelope format

The WS-* stack requires SOAP, an envelope format for WS-* sent message.  Considering how WS-* only tunnels over the HTTP protocol instead of leveraging it, it is understandable why an envelope format had to be developed.  The HTTP message format is good enough.  It is simple, robust, and flexible enough.

REST vs. WS-*

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.