- February 08, 2007

Even though REST was only formalized in 2000, it is fundamentally based on the Web architecture and its core standards: HTTP and URI. At the same time, efforts to port on the Web older technologies such as CORBA, RMI and DCOM resulted in the specification of SOAP, WSDL and soon after of a full stack of interrelated standards commonly known as WS-*.

While adopting the “Web Services” name as an umbrella for their specification efforts, WS-* proponents didn’t initially realize that they were actually porting an older “remote procedure call” paradigm on top of the Web. But, the Web was already a proven distributed system, based on a set of standards and an informal architecture. Thanks to the amazing work of Roy T. Fielding and a core group of REST proponents (often named RESTafarians) like Mark Baker and Paul Prescod (check this recent interview), the mismatch between both approaches became progressively evident.

This tension, often described as a battle, was in fact fruitful to both sides. The WS-* proponents realized that their approach brought in too much complexity, leading to inextricable interoperability issues (as an illustration, see this video from Simon Guest, a product manager at Microsoft). The REST proponents, within an active community, progressively built a common body of best practices and dedicated tools.

It seems to me that, like in 2000, we are at a cross-road. Hopefully, 2007 will be the year of reconciliation between both camps. REST proponents would understand and start to address more complex enterprise needs, like integration through business processes and provide more concrete guidance on REST usage and better tooling support. WS-* proponents would finally consider REST as the foundation of their architecture and would slowly refactor their stack of specifications into of simpler and coherent set. Everyone would benefit, first by stopping the waste of energy in endless pro/con arguments. REST would become a respected part of the SOA industry and WS-* would be respected as a real and usable Web Services platform.

The W3C members part of the Architecture Domain will meet at the end of February for a workshop on the Web of Services for Enterprise Computing. Looking at the position papers from Mark Baker, BEA, IBM, Iona, Progress Software or Yahoo!, it seems that the whole industry is finally going back on a more sensible track.

Update 1:

Update 2:

  • The presentations slides are now also available online
  • Eric Newcomer (Iona) has a nice two parts summary of the event! (part 1, part 2)
  • Paul Downey (BT), Paul Sandoz (Sun), Pete Lacey and Johnathan Marsh (WSO2) have also reported back
  • Dave Orchard also reported and talks about some ways of reconciling REST and WS-*, namely usage of WADL to formally describe REST applications and a new SOAP binding for HTTP/URI/XML that would be consumable by REST clients. That sounds like very useful propositions to me.

Update 3:

  • I certainly hope so!

  • Pingback: Web Things, by Mark Baker » Blog Archive » links for 2007-02-09()

  • Pingback: Stefan Tilkov's Random Stuff()

  • Um, why do we need to reconcile both camps when the approaches differ so much and both have advantages beyond their intersection. I’d much prefer us to emphasis the differences, and take the Web word away from SOAP.

  • By reconciling, I don’t mean merging and blurring the differences. For sure, the Web (REST/HTTP/URI) will stay as it is today. As you point in your paper (, SOAP 1.2, WS-Addressing and WSDL 2.0 already attempted to better take the Web Architecture into consideration with unconvincing results.

    However, I believe that we are all attempting to solve the same goals of SOA and this could be the basis of the reconciliation. The REST camp has to move up the stack to better address the needs of enterprises. For example, how do you concretely implement business process integration with REST? How do you ensure ACID properties? REST itself doesn’t solve all the interoperability issues (like the representation of business documents as XML/XSD and the binding to programming languages). I’m sure that the WS-* camp can bring valuable experience in these areas, at least so that we don’t make the same mistakes twice.

    The next step is probably to fully reformulate the whole WS-* stack based on REST/HTTP/URI specifications. Also, WADL could be used as the description language.

  • One unfortunate characterization of Web services, although perhaps appropriate (because of how they’ve been implemented) is that they are RPCs.

    The SOAP 1.1 specification says that “SOAP messages are fundamentally one-way transmissions from a sender to a receiver…”

    This is gone from the 1.2 spec, probably because it is more “informative” (i.e. more like an opinion or interpretation) than “normative” (i.e. required) information.

    But the statements about simplicity as a goal remain, including the deliberate omission of key features of object oriented technology (including “reliability”, “security”, “correlation”, “routing”, and “Message Exchange Patterns” (MEPs). An RPC is an instance of an MEP.

    I said for years that SOAP is not an RPC, and it certainly is not like RPCs we all know and love (i.e. DCE, IIOP, RMI) since one of the things it omits is the persistent session mechanism on top of which “traditional” RPCs layer their QoS features.

    But of course today it’s harder to say that since if you go by the definition of SOAP as implemented in products, most of the time what you see is RPC wrapping.

    Newer toolkits are starting to emphasize support for plain XML and REST style interactions – the document style SOAP has always been in the specs but it seems as if products implement either one or the other (JBI being a kind of outlying exception to this) but not both.

    Anyway I am glad to see this post because this sort of discussion is what I’m hoping for at the Workshop, and with any luck we’ll produce some good results in this area.

  • Pingback: Eric Newcomer's Weblog()

  • The recent release of WSDL 2.0 by the W3C has added a REST binding. This shows how things have changed since 2000 and how the 2 (3?4?5?) communities have been working together better….