Rendered at 06:59:52 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pjmlp 32 minutes ago [-]
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.
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.
mhl47 1 hours ago [-]
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.
bluegatty 3 minutes ago [-]
seems like a great idea, as long as it's well maintained etc
Muromec 1 hours ago [-]
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.
2 hours ago [-]
lestx 2 days ago [-]
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.
uncle_kostya 1 hours ago [-]
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.
motbus3 7 minutes ago [-]
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
belZaah 1 hours ago [-]
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?
kstrauser 3 hours ago [-]
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.
wwn_se 6 minutes 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.
bblb 2 hours 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
tyre 6 minutes 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.
qwertyuiop12 2 hours ago [-]
SOAP is good for flexible APIs due to xml “eats anything”, the “included” support for signatures and schema validation.
silon42 1 hours ago [-]
Ironically, most XML signatures I had to use, they usually didn't schema validate.
chrisandchris 52 minutes 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.
cyberax 2 hours 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?
justinclift 2 hours 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 2 hours 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 60 minutes 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.
userbinator 2 hours 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.
coredev_ 2 hours ago [-]
I think the biggest problems with SOAP was the implementations, never the standard. WCF...
anticensor 2 hours ago [-]
An adaptation of PEPPOL (also XML, but at least standardised)?
vintermann 30 minutes 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.
2 hours ago [-]
userbinator 2 hours 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 (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 1 hours 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 1 hours 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 2 hours 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 1 hours 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 4 minutes 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.
nidnogg 1 hours ago [-]
Why Postman? There are nicer, git friendlier options for something being shown as a git repo primarily.
p0w3n3d 1 hours ago [-]
Can you advise?
draxter 1 hours ago [-]
bruno, for one
pampas 1 hours ago [-]
.http files
tclancy 3 hours ago [-]
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.
kstrauser 2 hours ago [-]
It was last updated in 2001. I'd be shocked if it didn't have any relevant breaking changes in the last 25 years.
juusto 3 hours ago [-]
Great job. Are there any interesting facts or anecdotes you found while perusing content?
rtpg 2 hours ago [-]
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.
linohh 38 minutes ago [-]
There are a services which abstract that stuff away from you.
Scarbutt 2 hours ago [-]
What programming languages have the best ecosystems to interact with SOAP 1.2 ? What's your stack/libs to interact with it?
As for performance, that was also rediscovered why none of them are great, thus gRPC rediscovering CORBA, COM and Sun RPC.
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.
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.
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.
WS auth is horrible though and a bearer token (and tls) in the header is definitely the way to go.
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
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.
That‘s the question? And not why every single invoice has to go through the government?
I would call that developers loss of focus.
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. :(
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.
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
[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.