It isn't that bad, at least XML is machine friendly, supports schema validation, and does comments, contrary to its replacements that had to rediscover why such features matter.
As for performance, that was also rediscovered why none of them are great, thus gRPC rediscovering CORBA, COM and Sun RPC.
When we rolled out an ERP in our Brazil subsidiary the whole internal consulting team immediately agreed to leave our brains untouched by this complexity and hire a local consultant team as help. And the local consultant team in turn immediately suggested useing a middleware provider.
This sounds similar to Ukrainian cash registers. Every retail operation goes through a cash register API on the tax agency side (because who would not love to keep some cash off the books, right), but there it is RESP+JSON and a cottage industry of services running it for you. It would not even be that hard is it wasn't sneaking the whole PKI into it.
XML/SOAP based protocol was created with modern at the time .Net technologies, but nobody really cared about interoperability, so it screams "old .Net" now.
SOAP API in 2026 - this seems fine? Fundamentally we are talking about
exchanging XML documents over a request/response protocol, generally HTTP,
which is a still pretty well supported thing to do even in 2026.
The actual XML formats contained in the messages can be anything that can be
represented with an XML schema. Obviously some schemas are better designed than
others, but having a standard way to represent complex business documents with
well-defined composable components, nesting, and having sufficient flexibility
to handle defined variations of those documents is generally a good thing.
If you compare a good XML-based API implementation with the disaster that is
the v1/chat/completions JSON API, which is a monster to correctly deserialize
into typed structs, you will understand why XML protocols can still be a good
choice. The typical ad hoc JSON API has the advantage of being the lowest common
denominator, and does not require the designer to think much about their schema
before rushing to publish their API. JSON gives you lots of opportunities to
make design mistakes whose costs will largely be supported by consumers of the
API.
The SOAP spec itself is abandoned since 2007, but being built on other
protocols such as XML, HTTP, TLS, TCP means it has benefited from the advances
there. I don't see anything that is inherently outdated in the spec.
From my perspective, one of the biggest weaknesses is regarding the typical
authentication mechanism with SOAP, but the spec itself does not prescribe any
particular auth implementation. You can and should ignore WS-Security and
choose a simple bearer token or better yet mTLS if you want to avoid text-based
credentials being passed all over the place, often without any sane way to
revoke or rotate them.
I see some comments about WSDL and Go: hooklift/gowsdl worked fine for us. We
built a certificate automation platform in Go which interfaces with multiple
CAs through their APIs, and one of them handed us a WSDL file for their SOAP
API.
Other than some quirks with how the API handles namespaces and attributes which
I believe are due to a misconfigured XML parser on the backend, hooklift/gowsdl
worked great. The generated structs and functions worked fine after massaging
some of the serialization annotations to deal with the quirks.
This CA later told us they were going to replace their quirky but perfectly
functional SOAP API with a "REST API", which given that the cert issuance process
requires state, doesn't seem consistent as REST is a stateless protocol. I
think there is a tendency to call any JSON API a "REST API" to lend it
credence. My response was that they would be better served correctly
configuring their XML parser to handle namespaces as per their own WSDL
definitions so that using the WSDL to generate the code works without a bunch
of tweaks. I would much rather use a well-designed SOAP API than an ad hoc JSON
API strung together with liberal amounts of vibe coding, which is the current
trend.
This CA also had a unique authentication mechanism by requiring the credentials
to be placed in the body of each and every XML document sent to the API, in
plain text. So anything or anyone that needs to process, log or debug any XML
document also gets a copy of the credentials. Also the same password used to
log in to the web interface. Don't do that.
Brazil runs the largest mandatory e-invoicing system on Earth. Every invoice, every truckload, every retail receipt in a $2T economy passes through government SOAP 1.2 webservices. In 2026.
Want to integrate? The documentation is four PDF manuals totaling over 1,000 pages, spread across different portals, with critical details that are simply not written anywhere. Two examples we paid for in hours of debugging: the freight document (CT-e) and the manifest (MDF-e) implement the same distribution spec with incompatible envelopes (one wraps the payload and requires an author state code, the other rejects that field and wants the state code in the SOAP header). And the SOAP action must travel inside the Content-Type header; send a SOAPAction header like every SOAP tutorial on the internet tells you to, and the server refuses you without explaining why.
So we mapped all 29 webservices across the 4 document models into one Postman collection: ready-to-fire envelopes, per-host mTLS certificate setup documented, and the distribution services validated against the production government endpoints, not just written from the manuals.
Where you can make it better: Brazil has 27 states and several run their own authorizer URLs (Sao Paulo's retail invoices, for one). We cover the shared authorizer plus the national environment; state-specific URL mappings are the top open contribution. The collection is generated from a Python inventory file, so a PR is a 5-line diff, not JSON surgery.
Docs in Portuguese (the devs suffering with this are Brazilian), but I'll answer anything here in English.
SOAP 1.2 strikes me as really reasonable - it's a mature format with interop to several languages and has schema validation.
The inconsistencies you describe above are probably due to each org in the government implementing the common spec independently of the others, and introducing differences without even knowing. Documentation is key here, but as with any large system, there can be gaps.
It's really cool that you mapped it all.
And kudos to Brazil for creating a common computerized platform.
I once had to write some middleware for some warehouses based of an erp/crm subsidiary of the megacorp that rhymes with whoracle, the documentation was sparse specifically for the field I needed to modify, and once I got it working I saved 40MB of memory per PHP process by nuking the client side validator, fun times! The thrill of cobbling that together started me down the dark path to working for an API gateway appliance company, the darkness was immeasurable.
E-invoicing has been mandatory in Italy too for a while. The rollout started in 2014, but it took years to complete. The main integration system is based on the exchange of XML files via SFTP.
So sending an invoice means leaving an XML file in a folder, then polling the server and waiting a few hours to get a response in the form of another XML file in another folder.
You can also integrate via web service, but I think SFTP is still the most popular method, especially for its batching capabilities.
So, first up: why? Why is everything still using SOAP? I'm not talking down on Brazil, by the way. I've worked in American healthcare tech, and at some point you find yourself learning EDI to talk to insurance companies.
Maybe it's a solved problem and SOAP 1.2 is good enough for that particular job.
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
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.
> 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.
Eg Python is barely trudging along with random forks of a library that stopped being supported 10 years ago, each fork only getting maintained for about a year at a time.
I really think outside of Java and c#, soap is totally dead.
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.
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.
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.
> 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?
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. :(
Oh yes, part of the gigantic OASIS UBL (ISO/IEC 19845) and EN 16931 (CEN/TC 434). If young devs today think AI likes to build massive overengineered jargon-filled monstrosities, they should see what they learned it from. Never mind how to get a paycheck, we'll worry about that later, freeing humans from working on this stuff is a humanitarian obligation.
I implemented 837p during the ChangeHealthcare hacks. Once I got the hang of it, it wasn’t too difficult to build a library with OOP that could recursively render itself.
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.
SOAP is perfect for integration between organisations (for internal communication other formats is usually better). It supports schema first in a natural way meaning as long as both parties agree on a schema nothing else really need to be shared. XML is mature and supported in all languages with code generation its more or less transparent to the dev.
WS auth is horrible though and a bearer token (and tls) in the header is definitely the way to go.
> XML is mature and supported in all languages with code generation its more or less transparent to the dev.
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.
> 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.
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.
XML is not perfect, but it is mature. It has been the same for a very long time, all the warts and gotchas are well known. You need to be careful about the same things in 2026 as you did back in 2006.
The answer is probably "because SOAP was the hot new thing when they first decided to do this".
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...")
Sat in many meetings talking about CORBA and COM. And XML is the gift that just keeps giving. Thank god that stuff is in the rear view mirror.
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?
> 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.
SOAP is terrible[1], but if the whole country is on board, change is very difficult and you're not going to move to anything simpler because it would either be too simple to actually satisfy the need or too simple to satisfy the selection comittee.
[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.
I've had positive experiences with wsdls, they offer a lot of advantages over REST/JSON, together with some up front onboarding costs.
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.
Unfortunately that seems like bad history. I’ve only had good experience with wsdls, internally and externally, but they were generated with the services and readily available.
I have the same experience as you. I have probably worked with a few dozen SOAP services in my time, so perhaps I have been "lucky", but WSDLs have not been an issue for me.
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.
What’s the rationale of all this? I mean countries have gotten (mostly) rid of black books without such systems. Maintaining such a solution must be horribly expensive and what if it goes down?
Hold up, the alternatives I’m familiar are (UK) involve sending arbitrary documents which are read by humans, or ingressed into matching systems to then be checked by humans, so that key fields can be extracted…
I read every invoice goes through a standard interface an improvement, no?
I dealt with Brazil payment system before and if is not bad at all. If could be simpler, but it is a plain 3/5. But Brazil taxes cannot be built not even by PhD 600 GPU Next Gen Hacker AI
For .Net at least SOAP support is built in, just standard .Net, no libraries required, just ask Visual Studio to load the WSDL and it will handle the rest.
I haven't used it myself, but a former colleague speaks fondly of gSOAP for integrating into C. When we've talked about it, his take is that using gSOAP would vastly reduce complexity and development time (compared to Java and REST), but this is an older gentleman who has been writing C since the 1980s.
It’s been a long time since I had to work in SOAP. Does https://soapy.sourceforge.net/ atill work? That would make things easier to automate if so. This is awesome work.
have there been any "here's a nicer wrapper API" services out there? Or is the complexity somewhat upstream of "real" complexity/differences in reporting.
It isn't that bad, at least XML is machine friendly, supports schema validation, and does comments, contrary to its replacements that had to rediscover why such features matter.
As for performance, that was also rediscovered why none of them are great, thus gRPC rediscovering CORBA, COM and Sun RPC.
Comments were intentionally not included in JSON to prevent anyone adding extensions via preprocessor directives, IIRC
And then they added extensions anyway.
No they didn't? Stuff like JSONC or JSON lines are different formats from JSON.
When we rolled out an ERP in our Brazil subsidiary the whole internal consulting team immediately agreed to leave our brains untouched by this complexity and hire a local consultant team as help. And the local consultant team in turn immediately suggested useing a middleware provider.
This sounds similar to Ukrainian cash registers. Every retail operation goes through a cash register API on the tax agency side (because who would not love to keep some cash off the books, right), but there it is RESP+JSON and a cottage industry of services running it for you. It would not even be that hard is it wasn't sneaking the whole PKI into it.
Similar in Georgia https://eservices.rs.ge/app/Downloads
XML/SOAP based protocol was created with modern at the time .Net technologies, but nobody really cared about interoperability, so it screams "old .Net" now.
seems like a great idea, as long as it's well maintained etc
Every SAML IdP (and there are still a lot) using the Artifact binding runs on SOAP 1.2, so what.
Oh gosh. I could only imagine how many apps in chain crafts and parses soap envelopes with adhoc code with mandatory info loss.
SOAP API in 2026 - this seems fine? Fundamentally we are talking about exchanging XML documents over a request/response protocol, generally HTTP, which is a still pretty well supported thing to do even in 2026.
The actual XML formats contained in the messages can be anything that can be represented with an XML schema. Obviously some schemas are better designed than others, but having a standard way to represent complex business documents with well-defined composable components, nesting, and having sufficient flexibility to handle defined variations of those documents is generally a good thing.
If you compare a good XML-based API implementation with the disaster that is the v1/chat/completions JSON API, which is a monster to correctly deserialize into typed structs, you will understand why XML protocols can still be a good choice. The typical ad hoc JSON API has the advantage of being the lowest common denominator, and does not require the designer to think much about their schema before rushing to publish their API. JSON gives you lots of opportunities to make design mistakes whose costs will largely be supported by consumers of the API.
The SOAP spec itself is abandoned since 2007, but being built on other protocols such as XML, HTTP, TLS, TCP means it has benefited from the advances there. I don't see anything that is inherently outdated in the spec.
From my perspective, one of the biggest weaknesses is regarding the typical authentication mechanism with SOAP, but the spec itself does not prescribe any particular auth implementation. You can and should ignore WS-Security and choose a simple bearer token or better yet mTLS if you want to avoid text-based credentials being passed all over the place, often without any sane way to revoke or rotate them.
I see some comments about WSDL and Go: hooklift/gowsdl worked fine for us. We built a certificate automation platform in Go which interfaces with multiple CAs through their APIs, and one of them handed us a WSDL file for their SOAP API.
Other than some quirks with how the API handles namespaces and attributes which I believe are due to a misconfigured XML parser on the backend, hooklift/gowsdl worked great. The generated structs and functions worked fine after massaging some of the serialization annotations to deal with the quirks.
This CA later told us they were going to replace their quirky but perfectly functional SOAP API with a "REST API", which given that the cert issuance process requires state, doesn't seem consistent as REST is a stateless protocol. I think there is a tendency to call any JSON API a "REST API" to lend it credence. My response was that they would be better served correctly configuring their XML parser to handle namespaces as per their own WSDL definitions so that using the WSDL to generate the code works without a bunch of tweaks. I would much rather use a well-designed SOAP API than an ad hoc JSON API strung together with liberal amounts of vibe coding, which is the current trend.
This CA also had a unique authentication mechanism by requiring the credentials to be placed in the body of each and every XML document sent to the API, in plain text. So anything or anyone that needs to process, log or debug any XML document also gets a copy of the credentials. Also the same password used to log in to the web interface. Don't do that.
Brazil runs the largest mandatory e-invoicing system on Earth. Every invoice, every truckload, every retail receipt in a $2T economy passes through government SOAP 1.2 webservices. In 2026.
Want to integrate? The documentation is four PDF manuals totaling over 1,000 pages, spread across different portals, with critical details that are simply not written anywhere. Two examples we paid for in hours of debugging: the freight document (CT-e) and the manifest (MDF-e) implement the same distribution spec with incompatible envelopes (one wraps the payload and requires an author state code, the other rejects that field and wants the state code in the SOAP header). And the SOAP action must travel inside the Content-Type header; send a SOAPAction header like every SOAP tutorial on the internet tells you to, and the server refuses you without explaining why.
So we mapped all 29 webservices across the 4 document models into one Postman collection: ready-to-fire envelopes, per-host mTLS certificate setup documented, and the distribution services validated against the production government endpoints, not just written from the manuals.
Where you can make it better: Brazil has 27 states and several run their own authorizer URLs (Sao Paulo's retail invoices, for one). We cover the shared authorizer plus the national environment; state-specific URL mappings are the top open contribution. The collection is generated from a Python inventory file, so a PR is a 5-line diff, not JSON surgery.
Docs in Portuguese (the devs suffering with this are Brazilian), but I'll answer anything here in English.
SOAP 1.2 strikes me as really reasonable - it's a mature format with interop to several languages and has schema validation.
The inconsistencies you describe above are probably due to each org in the government implementing the common spec independently of the others, and introducing differences without even knowing. Documentation is key here, but as with any large system, there can be gaps.
It's really cool that you mapped it all.
And kudos to Brazil for creating a common computerized platform.
I once had to write some middleware for some warehouses based of an erp/crm subsidiary of the megacorp that rhymes with whoracle, the documentation was sparse specifically for the field I needed to modify, and once I got it working I saved 40MB of memory per PHP process by nuking the client side validator, fun times! The thrill of cobbling that together started me down the dark path to working for an API gateway appliance company, the darkness was immeasurable.
> The inconsistencies you describe above are probably due to each org in the government implementing the common spec independently of the others
So it’s not a great “common” spec?
E-invoicing has been mandatory in Italy too for a while. The rollout started in 2014, but it took years to complete. The main integration system is based on the exchange of XML files via SFTP.
So sending an invoice means leaving an XML file in a folder, then polling the server and waiting a few hours to get a response in the form of another XML file in another folder.
You can also integrate via web service, but I think SFTP is still the most popular method, especially for its batching capabilities.
This is on its way out and is being replaced by "Pan-European Public Procurement Online"
So, first up: why? Why is everything still using SOAP? I'm not talking down on Brazil, by the way. I've worked in American healthcare tech, and at some point you find yourself learning EDI to talk to insurance companies.
Maybe it's a solved problem and SOAP 1.2 is good enough for that particular job.
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
Why it _shouldn't_ be SOAP?
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?
> 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?
Eg Python is barely trudging along with random forks of a library that stopped being supported 10 years ago, each fork only getting maintained for about a year at a time.
I really think outside of Java and c#, soap is totally dead.
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.
> 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?
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. :(
sorry to hear that. if it’s any consolation, once you do get something that works, it tends to be pretty solid job security.
And what are the alternatives? JSON schema?
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.
I think the biggest problems with SOAP was the implementations, never the standard. WCF...
An adaptation of PEPPOL (also XML, but at least standardised)?
Oh yes, part of the gigantic OASIS UBL (ISO/IEC 19845) and EN 16931 (CEN/TC 434). If young devs today think AI likes to build massive overengineered jargon-filled monstrosities, they should see what they learned it from. Never mind how to get a paycheck, we'll worry about that later, freeing humans from working on this stuff is a humanitarian obligation.
I implemented 837p during the ChangeHealthcare hacks. Once I got the hang of it, it wasn’t too difficult to build a library with OOP that could recursively render itself.
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.
SOAP is good for flexible APIs due to xml “eats anything”, the “included” support for signatures and schema validation.
Ironically, most XML signatures I had to use, they usually didn't schema validate.
SOAP is perfect for integration between organisations (for internal communication other formats is usually better). It supports schema first in a natural way meaning as long as both parties agree on a schema nothing else really need to be shared. XML is mature and supported in all languages with code generation its more or less transparent to the dev.
WS auth is horrible though and a bearer token (and tls) in the header is definitely the way to go.
> XML is mature and supported in all languages with code generation its more or less transparent to the dev.
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.
> 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.
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.
Many libraries still have unsafe defaults. They come from the XML-age where security concerns were minor (SQL injection was still new to most!)
Using XML in a safe way requires you to study what is wrong with XML first. That is not what many people do.
XML is not perfect, but it is mature. It has been the same for a very long time, all the warts and gotchas are well known. You need to be careful about the same things in 2026 as you did back in 2006.
The answer is probably "because SOAP was the hot new thing when they first decided to do this".
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...")
Sat in many meetings talking about CORBA and COM. And XML is the gift that just keeps giving. Thank god that stuff is in the rear view mirror.
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?
> 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.
this is hacker poetry
SOAP is terrible[1], but if the whole country is on board, change is very difficult and you're not going to move to anything simpler because it would either be too simple to actually satisfy the need or too simple to satisfy the selection comittee.
[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.
I've had positive experiences with wsdls, they offer a lot of advantages over REST/JSON, together with some up front onboarding costs.
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.
Unfortunately that seems like bad history. I’ve only had good experience with wsdls, internally and externally, but they were generated with the services and readily available.
I have the same experience as you. I have probably worked with a few dozen SOAP services in my time, so perhaps I have been "lucky", but WSDLs have not been an issue for me.
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.
> So, first up: why? Why is everything still using SOAP?
That‘s the question? And not why every single invoice has to go through the government?
I would call that developers loss of focus.
What’s the rationale of all this? I mean countries have gotten (mostly) rid of black books without such systems. Maintaining such a solution must be horribly expensive and what if it goes down?
Hold up, the alternatives I’m familiar are (UK) involve sending arbitrary documents which are read by humans, or ingressed into matching systems to then be checked by humans, so that key fields can be extracted…
I read every invoice goes through a standard interface an improvement, no?
Why Postman? There are nicer, git friendlier options for something being shown as a git repo primarily.
Can you advise?
https://hurl.dev is pretty neat. As others have mentioned already - Bruno is also lean, dependable and recently got .yml support.
bruno, for one
.http files
I dealt with Brazil payment system before and if is not bad at all. If could be simpler, but it is a plain 3/5. But Brazil taxes cannot be built not even by PhD 600 GPU Next Gen Hacker AI
What programming languages have the best ecosystems to interact with SOAP 1.2 ? What's your stack/libs to interact with it?
Java, .Net and maybe C/C++
For .Net at least SOAP support is built in, just standard .Net, no libraries required, just ask Visual Studio to load the WSDL and it will handle the rest.
I haven't used it myself, but a former colleague speaks fondly of gSOAP for integrating into C. When we've talked about it, his take is that using gSOAP would vastly reduce complexity and development time (compared to Java and REST), but this is an older gentleman who has been writing C since the 1980s.
I was quite happy using Zeep on Python a few years ago, when I last had to do a custom SOAP integration.
It is a bit of an old-school experience, but all the important parts are there and get the work done.
Did you try to tell them about the incompatibilities and ways to improve? How did they react?
Great job. Are there any interesting facts or anecdotes you found while perusing content?
It’s been a long time since I had to work in SOAP. Does https://soapy.sourceforge.net/ atill work? That would make things easier to automate if so. This is awesome work.
It was last updated in 2001. I'd be shocked if it didn't have any relevant breaking changes in the last 25 years.
Clearly you never worked in soap. The whole idea was “web services but not easy”.
I’ll do you one better: if that’s the same project, I contributed to it: https://pypi.org/project/SOAPpy/#user-content-contributors
I recoil in horror at SOAP, not because I don’t know it, but because I do.
Ha, well thank you for giving me a much less painful SOAP experience than the usual one back in the 2000s. I’d first used it with .Net 1.1 or 2.0.
have there been any "here's a nicer wrapper API" services out there? Or is the complexity somewhat upstream of "real" complexity/differences in reporting.
There are a services which abstract that stuff away from you.
sounds like a great project!! ++1
Every country should have something like this