We _still_ use TCP/IP and it's v4 is from 1981.
edit: I once looked deep into Remote PowerShell. How it's actually built. Dear. God. XML enveloped inside XML inside another XML wrapped around HTTP. Add some certificate based encryption for the HTTP envelope and some more encryption for the Kerberos messaging inside the serialized XML wrapped in envelopes and wrappings. Now THAT'S a communication protocol. :D
WS auth is horrible though and a bearer token (and tls) in the header is definitely the way to go.
No, XML is still not mature. They still need to fix the security issues everyone reimplements every time such as local file disclosure via DTDs, exploding documents due to entity expansion and so on. It basically doesn't handle untrusted input well, like SQL built from strings without parameter bindings.
I hope this is reasonable and doesn't use XML Security or similar extensions that add a whole stack of other security issues on top that everyone reimplements when adding SAML support.
Who is doing this reimplementation? You're supposed to be using mature, battle-tested libraries for parsing these formats. Writing your own parser for just about any format is a fool's errand when good implementations that have already addressed these issues exist. Even a simple format like JSON is not immune to performance, safety, and correctness pitfalls.
Using XML in a safe way requires you to study what is wrong with XML first. That is not what many people do.
The real difficulty was payers who did not follow the spec, semantically. Whether to include certain fields or not and different interpretations of fields/values was maddening.
It's a perfectly fine protocol, with a rigid schema and mature code generation support for all relevant languages. It's not the sexiest protocol, but it gets the job done.
And what are the alternatives? JSON schema?
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'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.
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 really think outside of Java and c#, soap is totally dead.
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.
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.
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.
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.
Correct, yes I haven't.
Other members of staff where I'm working are from Java backgrounds, and have described (in detail) WSDL/XSD (when things are accurate) in positive terms as I put above.
And yeah, I'm presently dealing with vendor specs/docs that don't match what's actually sent over the wire, and it's a huge pain in the arse. And the vendor doesn't give a shit, as like you allude to they're in the telco business so the lock in aspect you mention is correct to. :(
ASN.1? It's even more mature, and the de-facto DER/BER encoding is far more efficient to generate and parse than anything XML-based.
Working with enterprise software is in general a horrific experience, especially that which originated in the 90s at the peak of OOP dogma-cults and insane architecture-astronautism abstraction mixed with SOLIDly thick levels of bureaucracy.
My memories of COM, CORBA, DCE/RPC, XML, etc. are not great. Some of the stuff reads like satire today, but people were actually serious about it: https://en.wikipedia.org/wiki/Object_Management_Group (I recall an article in a physical magazine long ago which started with "The Object Management Group's Working Task Force, also known as OMGWTF...")
However in the age of AI I don't know if it matters too much that SOAP is the interchange. It is easy enough to build clients against it. It works. It's probably quite secure. Who cares?
this is hacker poetry
That‘s the question? And not why every single invoice has to go through the government?
I would call that developers loss of focus.
[1] The whole thing with wsdl is like an elaborate prank. Without fail, the WSDL files are impossible to obtain and don't reflect the service as deployed or documented. Documented equivalent forms will not be treated as equivalent. Two instances of a 'standard' service will not accept the same XML. And I only worked with simple SOAP services with straight forward payloads.
WSDL is in some ways more user-friendly than openapi schemas. They have a rich set of types that mostly just work as expected. When I try to generate models from an OpenAPI JSON file, I often find myself either overriding the models or making scripts/plugins to rewrite the json to fix types. An example of this is using proper decimals instead of doubles, which is crucial in my line of work.
It really depends on the service, does it make it easy to obtain the wsdl and more importantly does it honor the type conventions. There is no getting around the fact that services need to maintain consistent behavior and document that behavior, the wsdl is just a transport layer for that organizational commitment. If you have the commitment, then you have a good experience, if you don't, you don't, and whether you are using JSON or SOAP doesn't matter.