Why use XML(SOAP) when JSON so simple and easy to handle?

I found the following on advantages of SOAP

• 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 formatted 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 has a way of specifying the data structure in a maturely formatted document (WSDL). JSON doesn't have a standard way of doing this.

If you are creating a client application and your server implementation is done with SOAP then you have to use SOAP in client side.

Also See here and here

Nowadays SOAP is a complete overkill, IMHO. It was nice to use it, nice to learn it, and it is beautiful we can use JSON now.

The only difference between SOAP and REST services (no matter whether using JSON) is that SOAP WS always has it's own WSDL document that could be easily transformed into a self-descriptive documentation while within REST you have to write the documentation for yourself (at least to document the data structures). Here are my cons'&'pros for both:

REST

Pros

• lightweight (in all means: no server- nor client-side extensions needed, no big chunks of XML are needed to be transfered here and there)
• free choice of the data format - it's up on you to decide whether you can use plain TXT, JSON, XML, or even create you own format of data
• most of the current data formats (and even if used XML) ensures that only the really required amount of data is transfered over HTTP while with SOAP for 5 bytes of data you need 1 kB of XML junk (exaggerated, ofc, but you got the point)

Cons

• even there are tools that could generate the documentation from docblock comments there is need to write such comments in very descriptive way if one wants to achieve a good documentation as well

SOAP

Pros

• has a WSDL that could be generated from even basic docblock comments (in many languages even without them) that works well as a documentation
  • even there are tools that could work with WSDL to give an enhanced try this request interface (while I do not know about any such tool for REST)
• strict data structure

Cons

• strict data structure
• uses an XML (only!) for data transfers while each request contains a lot of junk and the response contains five times more junk of information
• the need for external libraries (for client and/or server, though nowadays there are such libraries already a native part of many languages yet people always tend to use some third-party ones)

To conclude, I do not see a big reason to prefer SOAP over REST (and JSON). Both can do the same, there is a native support for JSON encoding and decoding in almost every popular web programming language and with JSON you have more freedom and the HTTP transfers are cleansed from lot of useless information junk. If I were to build any API now I would use REST with JSON.

I disagree a bit on the trend of JSON I see here. Although JSON is an order maginitude easier, I'd venture to say it's quite limited. For example, SOAP WS is not the last thing. Indeed, between soap client/server you now have enterprise services bus, authentification scheme based on crypto, user management, timestamping requests/replies, etc. For all of this, there're some huge software platforms that provide services around SOAP (well, "web services") and will inject stuff in your XML. So although JSON is probably enough for small projects and an order of magnitude easier there, I think it becomes quite limited if you have decoupled transmission control and content (ie. you develop the content stuff, the actual server, but all the transmission is managed by another team, the authentification by one more team, deployment by yet another team). I don't know if my experience at a big corp is relevant, but I'd say that JSON won't survive there. There are too many constraints on top of the basic need of data representation. So the problem is not JSON RPC itself, the problem is it misses the additional tools to manage the complexity that arises in complex applications (not to say that what you do is not complex, it's just that the software reflects the complexity of the company that produces it)