59

Receiving and sending data with JSON is done with simple HTTP requests. Whereas in SOAP, we need to take care of a lot of things. Parsing XML is also, sometimes, hard. Even Facebook uses JSON in Graph API. I still wonder why one should still use SOAP? Is there any reason or area where SOAP is still a better option? (Despite the data format)

Also, in simple client-server apps (like Mobile apps connected with a server), can SOAP give any advantage over JSON?

I will be very thankful if someone can enlist the major/prominent differences between JSON and SOAP considering the information I have provided(If there are any).

Umair Khan Jadoon
  • 2,874
  • 11
  • 42
  • 63
  • 1
    Does this answer your question? http://stackoverflow.com/questions/1237649/json-or-soap-xml – Nick Nov 30 '11 at 09:56
  • 5
    *"Parsing XML is also, sometimes, hard"* You shouldn't do it yourself - use the parser that comes with whatever framework you're coding on. – Geeky Guy Sep 20 '13 at 14:21

5 Answers5

35

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 a certain format: e.g. "Cart is a collection of Products and each Product can have these attributes, etc." A well put together WSDL document really has this nailed. See W3C specification: Web Services Description Language
  • JSON has similar ways of specifying this data structure — a JavaScript class comes to mind as the most common way of doing this — but a JavaScript class isn't really a data structure used for this purpose in any kind of agnostic, well established, widely used way.

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: Why use SOAP over JSON and custom data format in an “ENTERPRISE” application? [closed]

gfullam
  • 11,531
  • 5
  • 50
  • 64
Sunil Kumar Sahoo
  • 53,011
  • 55
  • 178
  • 243
  • 6
    Most people create their own SOAP objects anyway. – Mark Good Aug 20 '13 at 19:44
  • But is there any reason why JSON can't have predefined data structures just like XML? Why can't JSON have WSDL? By definition it may not but theres no reason why someone can't come up with a standard for it. I agree with "If you are creating client applicaiton and your server implementation is done with SOAP then you have to use SOAP in client side." But if you are creating both sides, JSON is fast. –  Dec 09 '13 at 16:22
  • 13
    JSON is now not limited to browsers anymore. You can have your entire backend written in JavaScript(node.js for example) and you can even pass raw JSON into the db(mongodb, elasticsearch, postgresql is cooking raw JSON support and validation too). If I were to choose between JSON and SOAP I would definitely choose JSON. – Renra Jan 15 '14 at 06:57
  • 14
    Avoid SOAP. JSON will do for any project.I already have 20 years software development experience including SOAP and can tell you that it has no real place in development anymore. There is nothing to be gained by SOAP. You waste a lot of time with bloatware and complexity, parsing performance, etc.. Almost no major software company (Google, Facebook, Microsoft) uses SOAP anymore. – Johann May 10 '14 at 08:11
  • 10
    Wow we've gone a long way since 2011, really it's quite amazing! Greetings from 2016! – Dmytro Jun 27 '16 at 05:32
  • SOAP parsing plus the XML format consumes a lot of bandwidth unlike JSON which doesn't rely on property naming convention, but instead uses brackets alone { }. Sadly, I work for an airline that still uses SOAP for their daily flights. – Wax Feb 22 '17 at 05:40
  • "JSON doesn't have a standard way of doing this.". It doesn't need to have any. Creation custom JSON validator is super simple in any programming language today. The rest of your answer is also deprecated. (vide server-side Node.js, many languages can compile their code to JS). – Marek Marczak Oct 26 '18 at 05:07
  • What is you can also provide your data structure in json? – TheRealChx101 Jul 25 '20 at 04:39
26

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.

shadyyx
  • 15,825
  • 6
  • 60
  • 95
  • I don't think this is really related to the question. REST is a different concept and incomparable to SOAP. The OP is talking about JSON vs XML SOAP. In my opinion REST is just no good for APIs. You try consuming a 3rd party api written to supply JSON, with no metadata, and you have to consume it on Android,iOs and WP... – Sentinel Jun 10 '15 at 08:04
  • 1
    REST and SOAP are different concepts. See this question https://stackoverflow.com/questions/19884295/soap-vs-rest-differences – lfk Oct 20 '17 at 00:49
  • Swagger can be utilized for documentation :p – Aimal Khan Feb 21 '19 at 01:28
  • It's funny how people are slowing adding around json that they already had for xml. Such as swagger and json-schema. Now people are even looking at different options for adding namespaces to json and relaxing the "standard" so they can add comments. – Matthew Whited Nov 02 '20 at 12:48
  • A big con of REST Is that it is not a RPC-based paradigm. This makes it hard to design it the right RESTful way in complicated scenarios. REST is basically limited (simplified) to sort of CRUD operations. The difference is not just the transmission format. Also with a bunch of good tools, you don't really need to worry about the underlying serialization format as a human. XML and JSON are serialization formats to be processed by machines. – user3625699 Apr 24 '23 at 22:56
8

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)

wiz21
  • 89
  • 1
  • 1
1

I think there is a lot of basic misinformation on this thread. SOAP, REST, XML, and JSON concepts seem to be mixed up in the responses.

Here is some clarification -

XML and JSON (an others) are encodings of information. SOAP is a communications protocol REST is an (Architecture) style

each is used for something different although you might use more than one of these things together.

Lets start with encoding data structures as XML vs JSON:

Everything JSON currently supports can be done in XML, but not the other way around. JSON will eventually adopt all the features that XML has, but its proponents haven't encountered all of the problems yet, once they get more experience things will be added on to close the gap. for example JSON didn't start out with Schemas and binary formats.

SOAP is a communication protocol for calling an operation. It runs on top of things like, HTTP, SMTP, etc. Aside from many other features, SOAP messages can span multiple "application" layer protocols. i.e. i can sent a SOAP message by HTTP to a service endpoint which then puts it on a message queue for another system. SOAP solves the problem of maintaining authentication, message authenticity, etc. as the requested moved between different parts of a distributed system.

JSON and other data formats canbe sent via SOAP. I work with some systems that sent binary fixed-width encoded objects via SOAP, its not a problem.

The analogy is that - if only the postman is allowed to send you a letter, then it is just HTTP, but if anyone can send you a letter, then you want SOAP. (i.e. message transport security vs message content security)

the 6 REST constraints are architectural style. Interestingly the first several years of REST the examples were in SOAP. (there is no such thing as REST or SOAP they are not opposites)

A "heavyweight bloated, etc.etc." SOA SOAP system might have monoliths with operations like GET, PUT, POST instances of a single entity. SOAP doesn't have those operations predefined, but that is typically how it is used.

Consider that if you built a "REST" service on HTTP alone with an SSL/TLS terminating proxy, then you may have violated the 4th constraint of REST.

So for your software development today, you wouldn't normally interact with any of these directly. Just as if you were written a graphics program you wouldn't directly work with HDMI vs. DisplayPort typically.

The question is do you understand architecturally what your system needs to do and configure it to use the mechanism that does that job. (for example, all the challenges of applying today's microservices to general systems are old problems previously solved by SOAP, CORBA and the old protocols)

Chris
  • 194
  • 6
0

I have spent several years writing SOAP web services (with JAX WS). They are not hard to write. And I love the idea of a single endpoint and single HTTP method (POST). For me, REST is too verbose.

But as a data container, JSON is simpler, smaller, more readable, more flexible, looks closer to programming languages.

So, I reinvented the wheel and created my own approach to writing backends for AJAX requests. In comparison:

REST:

RPC:

My way (the proposed name is JOH - JSON over HTTP):

  • get user: method POST https://example.com/ (JSON specifies both user ID and class/method responsible for handling request)
  • update user: method POST https://example.com/ (JSON specifies both user object and class/method responsible for handling request)
Yuriy N.
  • 4,936
  • 2
  • 38
  • 31