The Failure of SOAP

You know Craig, right now I tend to agree with you. But you too are old enough to realize that we'll start adding context (services, metrics, methodologies) till REST is SOAP is COM+ is MTS is COM is OLE and such.

My real question is: what we be ther silver bullet after REST ?

-- Henkk

I've made it through most of the book as well and was pleasantly surprised that the religious bits got over with quickly and there was good practical advice. I agree with you about GET/PUT. In some cases, there isn't an equal and opposite PUT for every GET. I use POST for updates, which means that the URIs are really processing endpoints rather than locations of concrete resources (which are what I GET). But I've learned to get past that inconsistent thinking.

Henk - I totally agree that the industry is likely to do that...only it didn't really happen with COM+. People just sort of learned that it hurt when they went like that and went back to doing things the simple, manual way. Unless you count SOAP a la WCF, I guess.

Anyway, I care less about what the industry does these days, and more about what *I* do. I'm glad to have had some insight about what the utility of the SOAP stacks actually is. That arms me to make better decisions for the future.

Erik - I think that as long as you make use of RESTish URL design, you're getting the main benefits, even when you use POST when you could use PUT. Further, I think if you design your web service to be usable via a modern browser (i.e. GET+POST, serve XHTML "microformats", use HTML forms) then you have a lot of practical benefits that weigh strongly in the balance against the supposed uniformity of interface that PUT and DELETE provide.

I think. :)

Resonates, resonates and all of which begs the question:

As for the next silver bullet, aka total freedom as the common-denominator:

Which tools, what stack, and where does it apply?

Any thoughts on that much appreciated Craig.

I have no idea. Right now I'm busy exploring LISP.

So regarding 'all but few edge cases', seems to me with Lisp or not, you will still end up looking for a good (liberating):

1. HTTP plumbing,
2. text/mark-up processing stack, and
3. some tools to transcend frameworks.

Am I missing something?

No, you're not missing anything. I'm going to start with LISP and see how far that takes me. It's an experiment.

HTTP plumbing is easy, though: IIS or Apache fit the bill nicely.

I agree in part - i do think that WCF should make interop with POST and GET easier. I am doing some stuff on precisely that at the moment as we need mobile phone clients in Java to be able to call them! I have it working, but although i like a REST approach to reading data, creating and updating is tricker.

In a more complex scenario - and most outside of demonstrations get that way pretty quickly - i like what WCF and SOAP give you (one of the first things i did was add SOAP headers to save passing tokens etc with every call body). I can go quickly to P2P and it's easy to separate my services and data in WCF.

We're in a era of plugging services on the web via simple API's at the moment, but longer term this will become complex again - it has to coz business rules are complex. If i want to update Twitter and Jaiku at the same time it's two POST's, but if i was updating something important i'd want a transaction to wrap them and so on. Heck, even it is wasn't i'd *like* this (i've got a lot of positive opportunities from "throw away" posts).

My concern is, and continues to be that i need to do work to get this to work on browsers and for other simple API clients. I'd like MS to have a tool that helps me do this and sets up the necessary settings (based on API usage scenario rather than pure service implementation).

A few comments:

* Why does it have to be WCF? WCF is designed to abstract the protocol. But the things that REST gives you are all about embracing the protocol. Sounds like a recipe for complexity to me. And indeed it is if you look at WCF in any detail.

* SOAP-the-format is not exclusive with REST. SOAP-the-protocol is. Go ahead and use SOAP payloads in your HTTP POSTs. Of course, if all you care about is headers, there are a million easy ways to do that. Cookies, for example.

* If you need to scale, then protocol independence is not a viable option. The idea that you can "just go P2P" inherently means abandoning things like eTags and cache control that are important for some apps. Maybe not for yours, though.

* It's trivial to design systems for transactions without having to resort to WS-*. What about HTTP makes you use two POSTs? Unless they're two different businesses, and then frankly you have a whole host of different problems that have nothing to do with technology. Also, I have a hard time thinking of a real world scenario where this would actually come up. When it does (e.g. banking), then WS-* is probably the right approach. I don't write apps like that, though.

* Tooling is somewhat of a concern, but frankly having spent the last five years working inside the scope of the tooling, I have found that it makes simple things simple and hard things hard. Which means I'm going to be reasonably well off doing it myself a lot of the time.

But I'm not trying to say that *you* don't need WCF and WS-*. Maybe you do - it certainly has its uses. Just like COM+ did and still does. Just that I think they're a lot fewer and farther between than I used to. To the point where I can't think of anything I've done that actually needs it.

I think that the biggest problem with SOAP are two of it's pillars: WSDL and XML Schema.

To quote Jim Webber, WSDL is a turd. That pretty much sums it up. Check out SSDL http://ssdl.org/ for a brilliant alternative.

XML Schema isn't so bad, it's the validation contraints that make it cumbersome. Schematron is the best tool for Doc-Literal validation, and RelaxNG is a decent alternative.

SOAP (+WS-Addressing) as the lowest abstraction in the WS stack is just fine, it's some of the things used along with it that make it ridiculous.

I should point out, that this post which claims to talk about the failure of SOAP, doesn't seem to really talk about the failure of SOAP. It simply talks about some alternatives to SOAP.

It seems like we're discussing a Known Truth(tm), that isn't well defined.

The article was attempting to say that SOAP is no longer *my* default choice for programming web services, in much the way that COM+ is no longer my default choice for programming transactional systems. And for many of the same reasons.

In that sense, I believe it failed to live up to the promise that many marketed it as having. I was one of the many who were out there promoting SOAP, so I certainly take my share of responsibility on that count.

If you thought I was trying to prove more than that, well, sorry. :) The title was as much a play on the title of a previous post as it was a comment on the success of SOAP: taken together, the two parts showed how one guy (me) wrote a very successful SOAP service and yet found the technology ultimately lacking compared to a simpler alternative. It's sort of a theme in my career. ;)