Ask HN: What was wrong with SOAP and WSDLs? | Hacker News Reader

Ask HN: What was wrong with SOAP and WSDLs?

6 pointsarduinomancer3 comments

I’m a new grad web developer and I’ve pretty much exclusively worked with REST apis as everywhere seems to preach their benefits.

The other day I happened to work on something that involved an old Java EE app that was using a SOAP based API.

I was blown away.

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?

Not only that but I can automatically generate client libraries for my API?

This might be naive but SOAP seems worlds better than REST from my impression.

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.

Furthermore it seems to rely on the developers to write good API docs which might get out of date easily.

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.

Now with that said, I wanna know why SOAP is actually terrible.

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

Was it about interoperability?

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.

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.

... a Solar box.

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

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

Reply on news.ycombinator.com