Hacker News Reader

I work on an SOA platform for a very large software company. We offer both REST and SOAP versions of our RPCs. In my experience, SOAP services are okay plug-and-play if you own both the provider and the consumer. But consuming external APIs can be nightmarish, especially with SOAP 1.2. SOAP exists in our organization for legacy reasons but we recommend all new consumers use RESTful services.

Our mobile clients like REST because it's faster and easier to consume from outside the .NET platform than SOAP. Even within the .NET platform, a client can get up and running consuming a "RESTful" service in fewer lines of code than a SOAPy one. Not only SOAP tooling, but HTTP client tooling in general, is a lot easier to use these days.

WSDLs are cool because they are a fairly standard metadata format. Our clients like them because they can perform data validation with proxy/firewall systems before the request ever enters the corporate network. I've yet to see a concrete benefit from that kind of strictness, though. IMO, SOAP schema validation is so brittle that it causes more problems than it fixes.

Of course, you can also use non-SOAP document description formats like RAML for describing your RESTful services. It's not like SOAP offers anything you can't get for REST. But once you start adding all that on top of your REST API stack, you might as well use SOAP 1.1. (Never use SOAP 1.2).

I don't think the main problem with SOAP is that it's over-engineered, although it is. The issue is that the supposed benefit of "interoperability" was never really realized. It's supposedly protocol-agnostic, but nobody cares. It's supposedly interoperable, but everyone implements it differently.

Very interesting! My knowledge was mostly based on hear-say, so it's great to get some details from someone with actual experience with SOAP.

What's wrong with SOAP 1.2?

It's too confusing, I think. The effort it takes to try to understand what's going on is too great. You can explain our REST service infrastructure to a developer in a few hours. I don't know how long it would take to explain the SOAP infrastructure, because I don't think anybody understands the whole thing.

If you are trying to communicate with a vendor that uses SOAP 1.2, it almost always seems to come down to guesswork. What set of properties do I need to specify before they accept my request? The WSDL gives you an object schema but it's not sufficient for the masses of WS-* extensions that you might have to support. Meanwhile, the vendor just exposes the WSDL and assumes that's sufficient "documentation" for clients and you don't need any examples or explanations or other info. I find the best way to approach this is to open Soap UI and start messing with settings until requests are accepted. There's no point asking the vendor for documentation because they probably don't know themselves.

Also, speaking from the perspective of a framework developer, I mainly start to pay attention when things stop working or clients are having problems. SOAP 1.2 doesn't have any more problems, but the problems are proportionally harder to solve. No matter how good your tooling is, it's not perfect, and it's a lot easier to look "under the covers" for RESTful services than for SOAP services. Of course that could also be attributed to the hellish nature of WCF, and not SOAP 1.2 per se.

This. So true!

    ...it almost always seems to come down to guesswork.

    Meanwhile, the vendor just exposes the WSDL and assumes
    that's sufficient "documentation" for clients and you 
    don't need any examples or explanations or other info. I 
    find the best way to approach this is to open Soap UI and 
    start messing with settings until requests are accepted. 
    There's no point asking the vendor for documentation 
    because they probably don't know themselves.

Having just dealt SOAP API last week, I can relate to this so much. I'm glad that I'm not the only one feeling the pain here.

I think the momentum is not on SOAP's side. But you are correct that it isn't going away, at least for legacy.

I'm writing something up on what was done right with SOAP and WS-*. (Arguably the code generation was useful for quite a few scenarios.)

> But has it really lost? I still see it used a lot in large corporate and high tech environments.

That's because of inertia -- a lot of those companies invested big in SOAP in the early to mid-2000s. They're not going to throw away an investment that big just because it's not cool anymore.

But don't mistake that inertia for SOAP being popular. It's just that so much money has been sunk into it that enterprise users are resigned to being stuck with it for a while.