16 ms·

I think SOAP has lost in a sense that it's no longer very popular around many web developers. But has it really lost? I still see it used a lot in large corpor

by treve 12y ago

I think SOAP has lost in a sense that it's no longer very popular around many web developers. But has it really lost? I still see it used a lot in large corporate and high tech environments. I was never a big fan of SOAP myself, but that's also partly because when I started, the tooling wasn't great and I got mostly a negative user-experience. But this is many years ago. My understand is that these days it's quite good, and it has a pretty good user-experience. Furthermore, everything is backed by xml schemas, which makes it easier to create and require strictly valid xml being sent back and forward. While some equivalents exist in REST-ish API's, it's arguably not very common and with SOAP it's a pretty much a free and built-in feature that everybody uses. Modern web API design is great for getting things up and running fast, but it's not amazing for rigorously robust design. I don't really like the "SOAP is bloated and over-engineered" narrative. It is uninteresting now, and was uninteresting 10 years ago. I think it's much more interesting to learn about the things that SOAP did get right, and see how we can apply some of these learnings in our API's.

keithba 12y ago
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.)
delluminatus 12y ago
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.
- treve 12y ago
  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?
  - delluminatus 12y ago
    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.
    - dotemacs 12y ago
      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.
smacktoward 12y ago
> 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.

by treve 12y ago

keithba 12y ago

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.)

delluminatus 12y ago

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.

treve 12y ago
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?
- delluminatus 12y ago
  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.
  - dotemacs 12y ago
    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.

smacktoward 12y ago

> 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.