
Ask HN: What was wrong with SOAP and WSDLs? - arduinomancer
I’m a new grad web developer and I’ve pretty much exclusively worked with REST apis as everywhere seems to preach their benefits.<p>The other day I happened to work on something that involved an old Java EE app that was using a SOAP based API.<p>I was blown away.<p>It seems like with SOAP the API is so well specified. I can read a single file and know the exact request and response types down to the exact types of the data structures?<p>Not only that but I can automatically generate client libraries for my API?<p>This might be naive but SOAP seems worlds better than REST from my impression.<p>REST feels so wishy washy and undefined as if no one actually understands how it should actually work. I’ve seen otherwise really good developers put verbs in the resource paths, and some operations feel really awkward to model in REST.<p>Furthermore it seems to rely on the developers to write good API docs which might get out of date easily.<p>To me it almost seems like REST vs RPC is like JavaScript vs a strong typed language. It seems better at first but falls apart when you start needing stronger structure and guarantees.<p>Now with that said, I wanna know why SOAP is actually terrible.<p>I’ve heard a lot of hate towards it and seeing as it sounds like it was abandoned I’m assuming I’m missing some crucial flaw here...<p>Was it about interoperability?<p>I can see how it’s easier to setup a quick request to a REST API in any language compared to XML but I’d have thought generated client libraries would solve this issue.
======
mindcrime
There isn't anything specifically _wrong_ with SOAP and for some applications
it's still the right choice. As with everything "use the right tool for the
job", whether it's SOAP, REST, DCOM, GraphQL, CORBA, ONC RPC, Thrift, DCE,
RMI, Avro, or $SOMETHING_ELSE.

That said, I think two major things gave SOAP a bad name and caused people to
look to alternatives in many situations:

1\. Lack of interoperability between major implementations. One of the whole
selling points of SOAP was that you should be able to implement a SOAP service
on, say, an IBM S/360 running COBOL, and then consume that service from a VB
app running on Windows 2000, in an app that also consumes a SOAP API written
in Java running on a Solar box. In reality, issues in the various
implementations - whether intentional or otherwise - made it far harder to
achieve that lofty goal than it should have been. That was especially true
early on. Things got better over time, but that really dinged SOAP and the
whole WS-* stack in the eyes of may people.

2\. The performance overhead due to XML (both the parsing, and the raw message
size due to XML being a little bit verbose).

Arguably a 3rd factor was the apparent complexity of things like XML
namespaces and XML schema, although I personally think that factor is a little
over-stated. Namespaces and schemas aren't actually all that hard to
understand.

Anyway, this industry tends to be _very_ faddish and once JSON came along and
became the next big shiny thing that got rid of the verbosity of XML, along
with schemas and namespaces, everybody suddenly jumped on the XML-RPC
bandwagon and, later, REST.

~~~
mindcrime
_... a Solar box._

That should, of course, read "... a Solaris box".

------
moonbug
[https://en.wikipedia.org/wiki/List_of_web_service_specificat...](https://en.wikipedia.org/wiki/List_of_web_service_specifications)
Pick a WS-* - any one - and start reading its spec. "The Enterprise", that's
what happened.

