I didn't do too much with SOAP back in the day and only got into web services while REST was gaining popularity. But when I go back and have to support a "legacy" system and integrate with SOAP, I'm still amazed at the maturity of some of the tooling around SOAP.

REST is getting there.

Personally, I think SOAP tooling can be a very leaky abstraction - things are great (e.g. adding a reference to a web service in Visual Studio is trivial) but then when something doesn't work quite as expected (particularly when calling between different tech platforms) debugging could be a nightmare.

My experiences with SOAP were that 99% of the time it was fine - but those other 1% seems to take the other 99% of my time... ;-)

Yes, my experience with SOAP is that even well written and maintained clients only work out-of-the-box with like half of the vendor-supplied services you come across.

In many cases, I'll simply formulate xml requests myself and use a generic http request client because the implementation ended up being simpler & easier to maintain than all the confusing hacks I had to do to make zeep or suds (the most popular SOAP clients implemented in python) function properly.

I don't hate SOAP, and I think it gets a terribly bad rap, but it's pretty easy to spit out a WSDL and not follow it in execution. Ditto OpenAPI, of course, but at least anecdotally it seems like less of a problem. It's not no problem, of course, and one of the reasons I wrote Modern[1], for OpenAPI 3, is to have response validation in development mode, not just request validation mode in dev and prod.

[1] - https://github.com/modern-project/modern-ruby

More than one SOAP interface that I encountered in "enterprise" systems consisted basically of:

   string DoStuff(string params)

Where the response and params are strings containing XML documents :-)