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.

View on HN

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