Why use SOAP over JSON and custom data format in an "ENTERPRISE" application? [closed]

Question

I work in a medium size financial company where all our applications talk to each other using SOAP and we only use JSON for AJAX requests from web sites.

Recently in a new project planning session, someone asked me why do we have to use SOAP for inter-application communication? Why not use JSON or even custom data format? In my heart I felt these alternatives are not "Enterprise-ready" but actually I couldn't think of a very compelling answer as to why they are bad.

The only two advantages of SOAP I can think of are tooling and security.

Modern IDEs such as Visual Studio have built-in utility to generate classes from WSDL definitions, which you don't get if you use JSON or custom data format. In terms of security, SOAP has well-defined security standards that are not available in other data format standards.

What do you think? do you use JSON as the data exchange format between applications?

Answer 1

The reason for JSON is simplicity. It's easy to read, easy to understand, has little overhead, and has implementations in just about every language.

To call something "enterprise" capable is a bit crazy, IMHO. It's just a data exchange format. Whether it's SOAP, XML, JSON, whatever, it's just a communication format.

Tooling is nice, I admit; auto-generated classes are great. But on the other hand, you get a lot of flexibility when you manage your classes by hand, and generally, it's not that difficult to do.

Security is a non-issue in my mind. Your data format should have (again, IMHO) nothing to do with your security. That needs to be at a different level entirely. While SOAP has some security extensions, etc, I think for the most part, they just provide a lot of unnecessary complexity. Ever tried reading some of the specs for the WS-Security? Yikes. How about just using JSON+HTTPS - easy, everyone supports it, and it works like a champ....

Now, that's not to say it's the right solution to every problem, but if you're just looking for data interchange, I'm sold.

Personally, I love JSON as a format, and use it all the time.

Answer 2

IMHO, there is one big reason everyone sticks with SOAP instead of using JSON. With every JSON setup, you're always coming up with your own data structure for each project. I don't mean how the data is encoded and passed, but how the data format is defined, the data model.

SOAP has an industry mature way of specifying that data will be in the form Cart is a collection of Products and each product can have these attributes, etc. A well put together WSDL document really has this nailed. Heck, it's a W3C specification.

JSON has similar ways of specifying this data structure. A JavaScript class comes to mind as the most common way of doing this. A JavaScript class isn't really a data structure in any kind of agnostic, well established, widely used way. Heck, JavaScript really only executes in one environment, the browser.

In short, SOAP as a way of specifying the data structure in a maturely formatted document (WSDL). JSON doesn't.

UPDATE: I have to say, I'm amazed by the number of down-votes this answer has gotten over the years esp given its accuracy at the time. I don't mean to hate on JSON, but after reading a recent article, I continue to stand by my previously made points. Meanwhile, JSON-RPC seems to be practically abandoned from a standardized format perspective (version 2.0 a proposal from 2010) and no other JSON protocols seemingly close to the level of SOAP's standardization. (Personally, this hasn't stopped me from embracing JSON-RPC 2.0 in production environments. I just would never use it in a proposal to a Fortune 500 company.)

To be clear, from an internal use perspective, JSON is GREAT. Lightweight. Fast. Widely used. Reasonably human-readable. But for enterprise, where multiple data streams are frequently merged. And data format specification between dozens of departments is necessary. XML is the established leader.

Answer 3

JSON does entail more effort that SOAP XML, but it typically produces much smaller packets, and is therefore more scalable. It is also (in my subjective opinion) vastly easier to read, while debugging, sniffing the wire, etc.