Don't throw out the SOAP with the bathwater

What goes around comes around. Three years ago, mine was one of the voices urging the Web services movement not to lose touch with the Web’s essential nature, as embodied in the architectural style known as REST (Representational State Transfer). Perverse devil’s advocate that I am, I’ll now switch sides and urge the REST movement not to dismiss Web services and SOA (service-oriented architecture).

This week, Yahoo launched a set of Web services that encapsulates all the important flavors of Yahoo search. Until now, these kinds of APIs -- Amazon’s, for example -- have offered dual interfaces, both SOAP and REST. Given the popularity of the REST option, though, do you even need SOAP? Yahoo decided that it did not. Its developer FAQ states, “We may provide SOAP interfaces in the future, if there is significant demand. We believe REST has a lower barrier to entry, is easier to use than SOAP, and is entirely sufficient for these services.”

I was tickled to see that, when defining REST, one of the articles Yahoo linked to was my own "The Beauty of REST," at XML.com. In that article I describe how and why the URL line -- that is, the browser’s equivalent of the operating system’s command line -- enables the kind of lightweight and viral integration that’s made my LibraryLookup project a success.

But as I’ve said before in this space, and as I’ll say again here, these two architectural styles need not conflict. WS-* and REST are complementary, and in fact many SOAP toolkits can expose services in a RESTian mode.

I agree that REST is entirely sufficient for Yahoo’s current API offering, which supports simple requests and responses. Using the URL line to open the request syntax to human searchers will accelerate innovative use of Yahoo’s services. So will the delivery of simple XML packets in the responses. Even though SOAP can work in a similar way, Yahoo made the right choice.

Now that the benefits of REST are abundantly clear, it’s time to circle back and ask when REST isn’t sufficient. The answer is that we’ll need the kinds of capabilities WS-* provides as our point-to-point, client/server-like applications evolve into webs of communicating services.

We’re mostly not there yet. On today’s Web, security, asynchrony, reliability, routing, and proxying are, in general, aspects of the data communications layer. On tomorrow’s Web they’ll be aspects of the application layer, and we’ll operate more like weavers of business processes than plumbers of networks.

We call that future Web a variety of names: grid, service bus, fabric. It will arrive, sooner or later, because it has to. Our challenge is to phase it in smoothly and incrementally, in ways that leverage and gracefully extend the RESTful Web.

The timing couldn’t be better. In May, exactly three years after I introduced the term REST to the pages of InfoWorld, I’ll be on the stage at InfoWorld’s SOA Executive Forum -- in San Jose, Calif., on May 5 and New York on May 17 -- with many of the leaders of the emerging SOA industry. How we marry the best of the first-generation Web with the best of the next-generation services fabric will be a top-of-mind question for me, and I’m really looking forward to the conversations we’ll have.