5 ms·

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 yo

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.

bblb 12d ago
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
cyberax 12d ago
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?
- userbinator 12d ago
  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.
- deleted 12d ago
  [deleted]
- coredev_ 12d ago
  I think the biggest problems with SOAP was the implementations, never the standard. WCF...
- justinclift 12d 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. :(
  - ivan_gammel 12d ago
    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.
    - justinclift 12d ago
      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.
  - mrweasel 12d ago
    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.
    - justinclift 12d ago
      > 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?
- anticensor 12d ago
  An adaptation of PEPPOL (also XML, but at least standardised)?
  - vintermann 12d ago
    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.
qwertyuiop12 12d ago
SOAP is good for flexible APIs due to xml “eats anything”, the “included” support for signatures and schema validation.
- silon42 12d ago
  Ironically, most XML signatures I had to use, they usually didn't schema validate.
userbinator 12d ago
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 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...")
- beachy 12d ago
  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?
- altmanaltman 12d ago
  > 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
toast0 12d ago
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.
- doc_ick 12d ago
  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.
  - qw 12d ago
    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.
- carefree-bob 10d ago
  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.
chrisandchris 12d ago
> 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.
wwn_se 12d ago
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.
- throwaway7356 12d ago
  > 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.
  - xienze 12d ago
    > 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.
    - throwaway7356 12d ago
      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.
  - 12d ago
tyre 12d ago
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.

bblb 12d ago

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

cyberax 12d ago

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?

userbinator 12d ago
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.
deleted 12d ago
[deleted]
coredev_ 12d ago
I think the biggest problems with SOAP was the implementations, never the standard. WCF...
justinclift 12d 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. :(
- ivan_gammel 12d ago
  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.
  - justinclift 12d ago
    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.
- mrweasel 12d ago
  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.
  - justinclift 12d ago
    > 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?
anticensor 12d ago
An adaptation of PEPPOL (also XML, but at least standardised)?
- vintermann 12d ago
  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.

qwertyuiop12 12d ago

SOAP is good for flexible APIs due to xml “eats anything”, the “included” support for signatures and schema validation.

silon42 12d ago
Ironically, most XML signatures I had to use, they usually didn't schema validate.

userbinator 12d ago

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

beachy 12d ago
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?
altmanaltman 12d ago
> 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

toast0 12d ago

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.

doc_ick 12d ago
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.
- qw 12d ago
  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.
carefree-bob 10d ago
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.

chrisandchris 12d ago

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

wwn_se 12d ago

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.

throwaway7356 12d ago
> 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.
- xienze 12d ago
  > 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.
  - throwaway7356 12d ago
    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.
- 12d ago

tyre 12d ago

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.