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