Comment by justinclift
6 hours ago
> mature code generation support for all relevant languages.
Heh, "relevant languages" is kind of an interesting term there. If the relevant language is Java then sure, it's fine.
Some popular modern languages (ie Go) don't have good SOAP support (yet). At least not to the point of being able to point them at WSDL/XSD specs and have everything auto-generated. :(
That seems like a Go problem. I don't exactly love SOAP and WSDL, but it was the default choice for Java and .Net 10 - 15 years ago in enterprise applications. Given the complexity, rewriting it a few years late, just to switch from a perfectly functional SOAP API to REST makes no sense and would mean that you either run two stack, or force every integrator to rewrite their software.
That's just no how the real world works. When this was launched Go probably wasn't a relevant language, Rust probably barely existed and the whole thing was designed for a corporate setting, where Java and .Net are the standards. All those who are asking "Why SOAP?" or suggests replacing it seems rather naive about how most corporate software is sold, designed, built and maintained, as well as expected lifetimes of solutions.
> That seems like a Go problem.
Yeah, fully agree. I was super surprised to find the SOAP support is practically non-existing too, as Go is really strong in lots of other areas. :(
That being said, SOAP's stronghold is clearly the Java ecosystem. Wonder if it's as popular in any other non-java-ecosystem based languages?
I think that‘s a matter of days and few hundred dollars in tokens to port it to Go if you really need it. Porting is where AI can do a really good job with the right instructions.
Yeah, kind of.
It's more than just a few days of effort though. Sme of the members of my team at work have been working on adding SOAP 1.1 support. It's a significant amount of time and effort though.
WSDL/XSD specs in this case seem to be incomplete or just wrong.
Most places in my experience just write their own wrappers/frameworks to generate what they know works, and go to town. I’ve done it too.
> WSDL/XSD specs in this case seem to be incomplete or just wrong.
Are you meaning in my comment, or in the GitHub repo the article references?
Asking because AFAIK the theory of having (accurate) vendor provided WSDL/XSD files is that you can generate a bunch of code (ie parsers, strong validation) that works with it, generate tests. There are additionally well developed SOAP specific GUIs (ie www.soapui.org) which will directly load the WSDL/XSD files and let you immediately make test network calls to validate things.
Though sure, you can do the above manually without WSDL/XSD files, but if you have accurate ones provided to you by vendors then it makes things a lot easier.
Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services?
Which is also my experience too.
Or have you not dealt with decade+ long services with severe inertia/lockin? Because that is what lets them get away with this.