Every invoice in Brazil's economy runs on SOAP 1.2

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.

This is on its way out and is being replaced by "Pan-European Public Procurement Online"

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

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.

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

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.

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?

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

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

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.

Can you advise?

It was last updated in 2001. I'd be shocked if it didn't have any relevant breaking changes in the last 25 years.

There are a services which abstract that stuff away from you.

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.