[pianoben]

If you deal with (some parts of) the public sector, you certainly will encounter SOAP. For example - those online drivers-ed courses you buy in California to get rid of a ticket? They all talk to a SOAP backend maintained by the State.

Certainly SOAP isn't everywhere the way it used to be (thankfully), but it's out there and isn't going away any time soon.

[WorldMaker]

> isn't going away any time soon.

Funny you think that. That's one of the major complaints about .NET 5+ is that WCF was dropped as an officially supported library and .NET is pushing people to REST and/or gRPC. (I think gRPC will suffer many of the same SOAP problems eventually, but it's the current hotness, thanks Google.) Every .NET HN article is full of complaints that WCF is dead and they have SOAP services to maintain and .NET is telling them to go away and do something new. There's a community project named CoreWCF trying to make the transition easier and even they are not trying to implement all of WS-* and SOAP madness and trying to make the transitions easier to REST or gRPC if you like that Google-branded SOAP smell better.

In .NET 5+ SOAP is already dead and good riddance. It's probably going to live forever on .NET Framework 4.x servers for legacy apps, but the message seems to be loud enough: "those are legacy apps now".

[benbristow]

SOAP isn't actually that bad if you use it with a typed language like C#. It's hell trying to use it with something like Ruby/Python though - I remember struggling to talk to a SOAP API with Ruby and getting into headaches that my data was being rejected until I realised that the XML properties had to be in the exact order unlike JSON which doesn't care usually.

Import a WSDL into Visual Studio and you've got your client code automatically generated & documented (if the API was written properly), works pretty nicely to be fair. Even easier than using something like Nswag to generate JSON clients from Swagger/OpenAPI specs.

[pianoben]

I never gave the Visual Studio WSDL code-generator the respect it deserved at the time. With hindsight, it was amazingly easy to use and generally "just worked".

> (if the API was written properly)

A very important caveat! I remember we hired some consultants from a world-renowned tech company - let's call them Big Red for now - and their big integration deliverable was a SOAP API with... one method. It accepted a string, and returned a string. And what was that one string? ...A SOAP request! The best code-generator in the world wouldn't have helped.

To this day I wonder if we actually ended up paying for that. I sure hope we didn't.

[lovich]

SOAP and the related libraries in .NET are pretty unfun to work with. However they are so old and unused compared to modern development that it’s not really a good comparison.

Like I have a Java app I am struggling with currently and not a fan of, but its on Java 8 so I don’t consider it representative of whatever I might find in modern Java despite the fact that I am working with it in modern times