November 15, 2007
@ 12:43 PM
Comments [13]
WS-* is to REST as Theory is to Practice

Recently someone asked in the comments to one of my posts why I seem to be down on the WS-* family of technologies (XSD, WSDL, SOAP, etc) when just a few years ago I worked on Microsoft’s implementations of some of these technologies and used to blog about them extensively.

I was composing a response when I stumbled on James Snell’s notes on the recent QCon conference that captures the spirit of my “conversion” if you want to call it that. He wrote

Those who are familiar with my history with IBM should know that I was once a *major* proponent of the WS-* approach. I was one of the original members of the IBM Emerging Technologies Toolkit team, I wrote so many articles on the subject during my first year with IBM that I was able to pay a down payment on my house without touching a dime of savings or regular paycheck, and I was involved in most of the internal efforts to design and prototype nearly all of the WS-* specifications. However, over the last two years I haven’t written a single line of code that has anything to do with WS-*. The reason for this change is simple: when I was working on WS-*, I never once worked on an application that solved a real business need. Everything I wrote back then were demos. Now that I’m working for IBM’s WebAhead group, building and supporting applications that are being used by tens of thousands of my fellow IBMers, I haven’t come across a single use case where WS-* would be a suitable fit. In contrast, during that same period of time, I’ve implemented no fewer than 10 Atom Publishing Protocol implementations, have helped a number of IBM products implement Atom and Atompub support, published thousands of Atom feeds within the firewall, etc. In every application we’re working on, there is an obvious need to apply the fundamental principles of the REST architectural style. The applications I build today are fundamentally based on HTTP, XML, Atom, JSON and XHTML.

My movement towards embracing building RESTful Web services from being a WS-* advocate is based on my experiences as someone who worked on the fundamental building blocks of these technologies and then as someone who became a user of these technologies when I moved to MSN Windows Live. The seeds were probably sown when I found myself writing code to convert Microsoft’s GetTopDownloads Web service to an RSS feed because the SOAP Web service was more complicated to deal with and less useful than an RSS feed. Later on I realized that RSS was the quintessential RESTful Web service and just asking people “How many RSS feeds does Microsoft produce?” versus how many SOAP endpoints does Microsoft expose is illuminating in itself.

Since then we’ve reached a world where thousands of applications being utilized by millions of end users are built on RESTful Web services on the public internet. My favorite example of the moment is the Facebook developer platform and before that it was Flickr and Amazon S3. Compare that with the number of SOAP and WS-* interfaces that are being used to build real developer platforms that benefit end users on the Web today.

Earlier today, I was contemplating Don Box’s recent post where he complained about the diversity of authentication schemes of various RESTful Web services from the “J. Random Facebook/Flickr/GData” services on the Web today. Don seems to hint that WS-Security/WS-Trust would somehow solve this problem which is rightfully debunked by Sam Ruby who points out that all those technologies do is give you a more complicated version of the extensible authentication story that is available in HTTP. So the only real issue here is that there are actually enough RESTful Web services on the Internet for Don Box to complain about the diversity that comes from having a flexible authentication model for Web services. On the other hand, there are so few useful public WS-* Web services on the Web (read: zero) that Don Box hadn’t encountered the same problem with WS-Security/WS-Trust since no one is actually using them.

At this point I realize I’m flogging a dead horse. The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already “invested” in WS-* and want to defend that investment.

At the end of the day, my job is to enable successful developer platforms that enrich our users’ lives not pimp a particular technology. So if you are one of my readers and were wondering what was behind my shift from thinking that WS-* related technologies were the cat’s pajamas and my current RESTful Web services/APP/GData/Web3S bent, now you know.

Enjoy.

Now playing: Brooke Valentine - Girlfight (feat. Big Boi & Lil Jon)


 

Categories: XML Web Services
Tracked by:
"I need a REST from SOAP (part1.1)" (obrienjd.com) [Trackback]
« Wedding Day Pictures | Home | Guidelines for Building RESTful Web Serv... »
Thursday, 15 November 2007 13:26:06 (GMT Standard Time, UTC+00:00)
From a practicle side, the current toolset in VS (and other platforms) makes it fairly easy for a developer to generate client-side proxies to call the service. The mechanics of the XML/SOAP request happen under-the-covers.

I think one thing that's missing from the current RESTful services is some kind of service definition language. I'm not saying it has to be XSD, but it should contain enough information about the service and parameters for tools to generate wrapper classes. While many popular RESTful API's have wrappers, that usually because the company has produced their own set of platform-specific API's to wrap the services... good luck if your platform of choice isn't one of them -- you need to write your own proxy to convert between the expected input/output formats...and that can lead to more errors.

However the service is published SOAP/REST, most developers would rather have a generated set of methods/classes to call it for them. Why keep rewriting parsing code?
Oren Novotny
Thursday, 15 November 2007 13:59:10 (GMT Standard Time, UTC+00:00)
>While many popular RESTful API's have wrappers, that usually because the company has produced their own set of platform-specific API's to wrap the services...

Exactly. The J. Random Facebook/Flickr/GData RESTful services of the world give you the best of both worlds. You get a platform specific wrapper if you are using on of the popular platforms (.NET/Java/Python/Perl/PHP/etc) and if you are some sort of esoteric language junkie, it still isn't hard to write straightforward XML parsing code to consume the results yourself.

> you need to write your own proxy to convert between the expected input/output formats...and that can lead to more errors.

The same kind of errors that occur if you used a different SOAP toolkit than the one the server is based on if you are doing WS-*. There's no way to get around platform differences when building distributed applications. The sooner people realize that, the better.
Dare Obasanjo
Thursday, 15 November 2007 14:49:14 (GMT Standard Time, UTC+00:00)
Excellent post Dare! In a way WS-* vs Rest reminds me of the first Jurassic Park movie where the following line is spoken:

"Life will find a way"

In terms of technology and API adoption a small change to that line reflects what is often the case:

"Simplicity will find a way"

Thanks for taking the time to create such informative and interesting posts!
ChessMess
Thursday, 15 November 2007 16:16:01 (GMT Standard Time, UTC+00:00)
Hey, don't bash WS-*, the MTOM feature is pretty neat. It makes transferring large file easier... over SOAP... because SOAP is heavy... and it's easier done in straight HTTP... oh. Ok, I see your point now ;)
Chad Myers
Thursday, 15 November 2007 19:37:56 (GMT Standard Time, UTC+00:00)
Is it possible REST is better suited for large-scale public an selecte private services, while WS* is better suited for distributed systems within and across the firewall? Or will SAP, Oracle, and other enterprise vendors simply expose RESTful APIs to their systems as well, and eliminate any need for WS* on the surface.

This then raises another question: when sending orders from Siebel to SAP there is a need for transactions, typing, reliable messaging, and security to name a few. How will REST handle these requirements without developing its own set of bloated specifications? It is my understanding, for instance, that Google uses SOAP for its PayPal-like checkout service, while using its ATOM-base APIs for its other service exposition, which do not require the level of transactional support that checkout service does. The average enterprise certianly wants to expose its services to the world, but many of its immediate requirements revolve around getting data to and from many internal and external systems.

I ask these questions as an original WS* proponent that sees the momentum moving to REST.

Robert Eisenberg
Thursday, 15 November 2007 19:59:34 (GMT Standard Time, UTC+00:00)
Thanks.

I always felt that I "should" be using the WS-* stack more. But it was simply easier for external developers to just use our plain old XML API.

Given the nature of our services (financial transactions), the number of external API clients coming from platforms without the latest and greatest WS-* support ecosystem by far outnumbered the minuscule amount of people (2 persons) using the "proper" web services, so we dropped support for it, more effort than it was worth.

For our security story, we went and re-used some ideas from existing services where no valuable credentials go over the wire (user generates throwaway tokens and keys for API usage), and just cheap old full payload encryption (if required by the particular customer/acquiring bank), or simple bidirectional message signing/MACing. Since we have full control of the format, I expect it will be somewhat harder to implement this in terms of WS-Security/WS-Trust, and still have customers be able to integrate without much hassle.

@Robert: I come it from a similar angle. We're finding our customers and partners (banks and large merchants) are pretty open to something that isn't necessarily based on the WS-* collective. Secondly, what makes SOAP in itself more "transactional"? We're processing a significant number of financial transactions a month without the help of SOAP :) The web services are just the entrypoint into our switch.
nexusprime
Thursday, 15 November 2007 20:03:57 (GMT Standard Time, UTC+00:00)
@Robert: The Google Checkout API is REST XML-based API. It does not use SOAP even for the asynchronous notification services.
James Arendt
Friday, 16 November 2007 00:31:59 (GMT Standard Time, UTC+00:00)
"REST" still suffers mightily from no real guidance on how exactly to construct something REST-ful. A dissertation doesn't cut it.
pwb
Friday, 16 November 2007 08:44:45 (GMT Standard Time, UTC+00:00)
REST is used on public web services more often. That's for sure and also easy to explain, because if you provide something to an unknown mass, you have to reduce the requirements. In that sense, REST is a very good choice, because you just require HTTP, etc. But that doesn't mean that REST is used more often. If you take a look into companies you will notice that there is a big usage of WS* services, but those services are just not public. Just because you can't see the WS* usage doesn't mean it doesn't exist!


Sebastian
Sebastian
Friday, 16 November 2007 10:37:06 (GMT Standard Time, UTC+00:00)
With respect to REST vs SOAP, you will find very interesting the following discussion:
http://tssblog.blogs.techtarget.com/2007/06/12/neward-and-trenaman-consider-rest-or-the-great-and-complete-soap-vs-pox-debate/

According it seems that SOAP has some advantages over REST.. what do you think?

Enric Jaen
Friday, 16 November 2007 14:08:01 (GMT Standard Time, UTC+00:00)
Your argument seems to be based on 'There are more Rest services out there so REST is better' . REST v/s WS-* is not a true comparison shouldn't it be REST v/s SOAP? In all the places i have worked , people prefer to use SOAP (to avoid dealing with any XML) (I dont make these decisions and I dont have it to justify them).
Perhaps the basic difference is WS-* attempts to solve a hard problem (unsuccessfully) whereas REST leaves you to figure it out based on your application.
deepak shetty
Friday, 16 November 2007 17:08:11 (GMT Standard Time, UTC+00:00)
Bravo. All I have to say is that REST is good example where the market is deciding who the winner is going to be. I do have to agree somewhat with Don Box though. While http authentication may be enough for some services, others are going to require a bit more security on the message itself. But maybe just using xml payloads with standard encryption mechanisms is good enough. It will be interesting to see how the enterprise side of this shakes out. While the public web services from the providers above are more popular, because they can be consumed easier, public web services have very different needs from b2b web services. Although I do have to say though that simpler is *almost* always better.
Justin Etheredge
Friday, 16 November 2007 17:22:37 (GMT Standard Time, UTC+00:00)
I don't know Dare. I think what you are calling REST is just part of REST, actually just how services were built before SOAP hopping along, which leaves, er, the rest unproven still.
Don Park
Comments are closed.