This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
It seems like we are more and more moving from a SOAP to a more RESTful world. A lot of APIs provide us with JSON responses for (easier) processing. However processing large JSON arrays consumes a lot of memory. Processing JSON is easier than processing XML responses with e.g. SAX and fortunately projects like ksoap2-android provide us with a lightweight library to process SOAP responses. But is it really lightweight?
If -- for example -- I need to setup a new service back-end for an Android application, with your experience, what would you suggest to write: A SOAP or a RESTful/JSON service?
Johan Pelgrim, The Netherlands
SCJP 1.4, SCWCD 1.4, SCBCD 5.0
I'm neither Satya or Dave, but I'd like to chime in on this thread because I'm very interested in varied opinions. I personally think JSON is described as lightweight due to its leanness with regards to the amount of data that must be transmitted over the wire. CPU time to process and memory to store, while not infinite, are certainly less costly than the bandwidth used -- doubly so if you consider the potential for carrier charges.
Thanks for commenting! I hear what you are saying, however... When -- for example -- you look at the twitter API for status updates for e.g. Andy Rubin the JSON response is 6.6Kb and the XML Response is 10Kb. Of course this is a significant difference, but not drastic in my opinion. I'm more interested in terms of productivity, maintainability and readability of the code rather than less bandwidth.
Joined: Feb 04, 2010
Great points and applying real world data makes it meaningful! Stated plainly you can be a proponent for XML with "the JSON response is only 1/3 smaller" or a JSON fan-boy with "the XML response is 50% larger!"
I couldn't agree more with the bullets in your final sentence regarding: maintainability & readability. Have you looked at GSON? It sure makes getting JSON into and out of Java data objects much easier! In fact, I've written a small routine that lets me cache a data object in app preferences with .toJson(obj) and .fromJson() GSON methods.
I hope others, including Satya and Dave join in the discussion.
Thank you for a wonderful question. Dave is perhaps the better expert on this.
However here is my short answer.
Android so far in all the releases hasn't made an explicit effort to support SOAP. Nor does it support explicit Java/XML binding. Even for its internal work of converting the declarative UI (defiend in XML) to corresponding Java objects is done through a plain fast SAX parser.
So REST/JSON has been a preferred method for newly architected solutions. Android comes with org.json package. There are libraries that support this. The most popular is GSON. However a library called Jackson is gaining fast ground as GSON seem to be very slow. I recommend that you give Jackson a try.
On the SOAP front, a variant of SOAP called ksoap, looks like has been ported to android. You may want to look up ksoap site to see if it is compatible to call existing soap services. Some folks are using SOAP UI to generate a SOAP XML stub/template and then filling in, simulating a SOAP call through http client. There seem to be some home grown/commercial soap clients such as wsclient. The commerical "wsclient" seem real nice and seem to be architected better for Android.
I have posted my research on this topic at my site
Great thread! Well, to add my two cents worth, I would choose JSON over SOAP. I also like the Jackson parser because it is a lot faster than the built-in Android JSON. Here's an interesting post on benchmarks:
I think the other thing to consider is whether or not you're going to want to reuse your services with a web-based interface. That'll be a lot easier with JSON than with SOAP. One other point I'd like to make is that if you're dealing with an existing SOAP service that you cannot change, you can always proxy it with another server-based service, so your Android client talks to your service using JSON and your server talks to the SOAP service.
just a question from a newbie in android development, if your app has to use .NET web service's, which most of then just use common SOAP objects, what is the way to go from there. For example the web services i found were sending serialized objects, and i deserialize them in java code and create the object back again. the object is JSON .
If you're stuck with SOAP web services, you have a few options:
1) Write the code yourself to create and parse the XML required to interface with the service. This can be a lot of work but it's certainly doable. It sounds like you're doing this. There's nothing wrong with it, but it takes time.
2) Use a package such as ksoap2-android.
3) Write a proxy web service on a server somewhere that sits between your app on Android devices and the final SOAP web service. Your app could talk whatever you want to your proxy web service, and your proxy web service can do the SOAP interfaces with the SOAP web service. Obviously this adds a major component to the mix, but may offer other benefits if you wanted to implement a subscription model for instance.