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