4 ms·

You’re comparing SOAP, a message protocol, with JSON, a data format. SOAP is so much more, it specifies how objects are defined, how they should be serialized a

by bouke 8y ago

You’re comparing SOAP, a message protocol, with JSON, a data format. SOAP is so much more, it specifies how objects are defined, how they should be serialized and delivered to a server (WSDL). Note that JSON doesn’t have anything like this that has seriously taken off. There’s a few attempts, but they aren’t in great use or have tooling support. So as a result everyone working with JSON implements their own de-/serializer, resulting in all sorts of errors. SOAP on the other hand takes care of this and even has a formalized date type and various number types. Your complaint is about two vendors creating incompatible inplementations/extensions. I’ve run into this as well and causes a lot of issues with compliant implementations that cannot work together. I think this has been a big reason why eventually SOAP will die.

donmatito 8y ago
I think parent's point was that with JSON you are, in most langages, a JSON.parse(payload) away from a message protocol. I am interfacing our startup's services with legacy (insurers) systems. We don't use the same programming langage. The docs are missing. Yet, we somehow manage to set up a functional API with minimal pain using JSON. When I compare that, to the amount of documentation a SOAP service requires (for another partner), I find JSON much more usable
sametmax 8y ago
Yeah but most projects I worked on used soap as a data format. I had to interface with a french administration that parsed the xml manually (poeple printed and read it) and an american administration that used regex to read the xml. Just having devs reading the dom correctly, including namespaces, is a rare occurence. It's sad, but we are living in a time were too many software is written, and not enough competent devs are available. So simplicity, again, wins.
sidstling 8y ago
I did specifically say it wasn’t technically the languages fault, but you certainly have a point. I don’t think it’s completely unreasonable to bring in SOAP even though you’re talking about the language, because I’ve almost never worked with XML without also working with SOAP. But in not completely comparing it to JSON either, I mean, I love JSON for the efficiency of transferring it between systems, so I’m not completely comparing XML/SOAP to JSON the language either. As far as lifecycle goes, it’s not actually the SOAP call but the way the two tech stacks parse the XML that’s the problem. You can also do rest calls with livecycle, and you’ll run into the same problems trying to pass XML created by any of the standard .net libraries to it. I agree SOAP is terrible, but part of my point is that SOAP taints XML, because it’s a really common way to transfer XML. I do use XML in other ways of course. We get quite a few datadumps in XML, that I turn to SQL through Microsoft SSIS, and even here it’s annoying. Not so much the language, but the way it breaks your SSIS service if it’s not delivered exactly as specified in its schema. Obviously that shouldn’t happen, but it does. Sometimes a supplier delivers half a file, and everything because SSIS didn’t get the XML specified in the schematic. (The fact that this breaks this is another wonderful story, where multiple datasets gets delivered within the same XML file.) JSON and XML are languages, as you say, but their main usage (at least for me) is transferring data between systems and techs, and that is almost always easier, simpler and safer with JSON. Maybe it’s unfair to call JSON the better language because of that, but it’s certainly more useful to me.

by bouke 8y ago

donmatito 8y ago

I think parent's point was that with JSON you are, in most langages, a JSON.parse(payload) away from a message protocol. I am interfacing our startup's services with legacy (insurers) systems. We don't use the same programming langage. The docs are missing. Yet, we somehow manage to set up a functional API with minimal pain using JSON. When I compare that, to the amount of documentation a SOAP service requires (for another partner), I find JSON much more usable

sametmax 8y ago

Yeah but most projects I worked on used soap as a data format. I had to interface with a french administration that parsed the xml manually (poeple printed and read it) and an american administration that used regex to read the xml. Just having devs reading the dom correctly, including namespaces, is a rare occurence. It's sad, but we are living in a time were too many software is written, and not enough competent devs are available. So simplicity, again, wins.

sidstling 8y ago

I did specifically say it wasn’t technically the languages fault, but you certainly have a point. I don’t think it’s completely unreasonable to bring in SOAP even though you’re talking about the language, because I’ve almost never worked with XML without also working with SOAP. But in not completely comparing it to JSON either, I mean, I love JSON for the efficiency of transferring it between systems, so I’m not completely comparing XML/SOAP to JSON the language either. As far as lifecycle goes, it’s not actually the SOAP call but the way the two tech stacks parse the XML that’s the problem. You can also do rest calls with livecycle, and you’ll run into the same problems trying to pass XML created by any of the standard .net libraries to it. I agree SOAP is terrible, but part of my point is that SOAP taints XML, because it’s a really common way to transfer XML. I do use XML in other ways of course. We get quite a few datadumps in XML, that I turn to SQL through Microsoft SSIS, and even here it’s annoying. Not so much the language, but the way it breaks your SSIS service if it’s not delivered exactly as specified in its schema. Obviously that shouldn’t happen, but it does. Sometimes a supplier delivers half a file, and everything because SSIS didn’t get the XML specified in the schematic. (The fact that this breaks this is another wonderful story, where multiple datasets gets delivered within the same XML file.) JSON and XML are languages, as you say, but their main usage (at least for me) is transferring data between systems and techs, and that is almost always easier, simpler and safer with JSON. Maybe it’s unfair to call JSON the better language because of that, but it’s certainly more useful to me.