3 ms·

And I am still struggling about the argument of why SOAP is bad but JSON RPC is good. The xml vs json debate is a tab vs double space debate to me.

by cm2187 4y ago

jeltz 4y ago
I have done a ton of integrations including many SOAP ones and it is because the SOAP standard is way too big, especially if we include XSDs. I have never used a SOAP library which implements the whole spec and it is very common for XSDs generated by one SOAP library to generate incompatible client code if you use another library (e.g. .NET and Java SOAP libraries are not compatible in some edge cases). I have quite often had to manually implement my own bespoke SOAP client (on top of some XML library obviously) due to the popular SOAP libraries not supporting the XSD I got. So SOAP is too big and all or virtually all libraries are more or less broken. I have never personally worked with such a broken mess of a protocol as the SOAP ecosystem. EDIFACT is supposed to be worse but I never worked with it, that was just some of my colleagues. JSON-RPC on the other hand is simple and all libraries I have seen implement it correctly and even if there is no library you can easily handroll everything.
- magicalhippo 4y ago
  > EDIFACT is supposed to be worse I've worked with all three, and I think SOAP is the worst. EDIFACT is huge, but the structuring of the elements are pretty well defined. I've had to both consume and generate non-trivial EDIFACTs and while it looks quite weird it's easy to do and easy to debug, at least in my experience. Except for trivial stuff, SOAP as always been a nightmare for me. We've tried tooling but there always incompatibilities and workarounds needed in our experience. These days I manually generate the SOAP envelopes for each integration we do, with potentially some processing of the payloads as well. While XML is verbose, with a good XSD that doesn't try to be fancy I find it quite nice to work with. Even the signed XML stuff (XMLDSIG), which while it took some time getting into, turned out to be not hard to implement due to tools and libraries that worked. So XML in itself is nice, it's just SOAP that manages to make it all hard for no good reason. JSON-RPC is easy enough, tons of JSON libraries out there that can be used if you need to hand-roll.
nsonha 4y ago
> why SOAP is bad but JSON RPC is good probably tooling, I haven't looked into it but whatever tooling available back in those SOAP days probably had poor UX. These days if there is a will to make either SOAP or JSON-RPC the way, the community could probably make better and more tools. Having said they both look shit to me :)). I guess if we go with the assumption that there will be tools to help with debug etc then the whole appeal of text based protocols disappears and you wonder why use such inefficient transports.
sanxiyn 4y ago
Who said SOAP is bad? SOAP is good. bugs.debian.org provides SOAP API, and it just works. I imagine maybe SOAP was bad when libraries and tools were immature.

And I am still struggling about the argument of why SOAP is bad but JSON RPC is good. The xml vs json debate is a tab vs double space debate to me.

by cm2187 4y ago

And I am still struggling about the argument of why SOAP is bad but JSON RPC is good. The xml vs json debate is a tab vs double space debate to me.

jeltz 4y ago

I have done a ton of integrations including many SOAP ones and it is because the SOAP standard is way too big, especially if we include XSDs. I have never used a SOAP library which implements the whole spec and it is very common for XSDs generated by one SOAP library to generate incompatible client code if you use another library (e.g. .NET and Java SOAP libraries are not compatible in some edge cases). I have quite often had to manually implement my own bespoke SOAP client (on top of some XML library obviously) due to the popular SOAP libraries not supporting the XSD I got. So SOAP is too big and all or virtually all libraries are more or less broken. I have never personally worked with such a broken mess of a protocol as the SOAP ecosystem. EDIFACT is supposed to be worse but I never worked with it, that was just some of my colleagues. JSON-RPC on the other hand is simple and all libraries I have seen implement it correctly and even if there is no library you can easily handroll everything.

magicalhippo 4y ago
> EDIFACT is supposed to be worse I've worked with all three, and I think SOAP is the worst. EDIFACT is huge, but the structuring of the elements are pretty well defined. I've had to both consume and generate non-trivial EDIFACTs and while it looks quite weird it's easy to do and easy to debug, at least in my experience. Except for trivial stuff, SOAP as always been a nightmare for me. We've tried tooling but there always incompatibilities and workarounds needed in our experience. These days I manually generate the SOAP envelopes for each integration we do, with potentially some processing of the payloads as well. While XML is verbose, with a good XSD that doesn't try to be fancy I find it quite nice to work with. Even the signed XML stuff (XMLDSIG), which while it took some time getting into, turned out to be not hard to implement due to tools and libraries that worked. So XML in itself is nice, it's just SOAP that manages to make it all hard for no good reason. JSON-RPC is easy enough, tons of JSON libraries out there that can be used if you need to hand-roll.

nsonha 4y ago

> why SOAP is bad but JSON RPC is good probably tooling, I haven't looked into it but whatever tooling available back in those SOAP days probably had poor UX. These days if there is a will to make either SOAP or JSON-RPC the way, the community could probably make better and more tools. Having said they both look shit to me :)). I guess if we go with the assumption that there will be tools to help with debug etc then the whole appeal of text based protocols disappears and you wonder why use such inefficient transports.

sanxiyn 4y ago

Who said SOAP is bad? SOAP is good. bugs.debian.org provides SOAP API, and it just works. I imagine maybe SOAP was bad when libraries and tools were immature.