Mobile Web Services – JSON/REST vs. XML/SOAP

As companies become more interested in exposing web services to get data to mobile apps, the question is always “what format should we use for the services?” It seems like JSON is the default most of the time lately – but larger companies often have existing investments in XML-based web services, or they’re using some enterprise web services stack, middleware, or ESB that doesn’t have great REST/JSON support. JSON is clearly the lighter format, but I don’t think it should be the default answer. SOAP/XML and REST/JSON each have their own advantages and disadvantages, and work in different ways across various mobile platforms with regards to speed of application development, ease of consumption, message size and performance.

Performance

In the context of this article, by “performance” I mean the speed of serializing and deserializing the formats. After some quick serialization tests pitting Json.NET against the WCF DataContractSerializer (the default .NET SOAP serializer), it appeared that the DataContractSerializer was about twice as fast when serializing 50,000 basic objects. The average Json.NET serialization speed was 0.976 seconds, and the average DataContractSerializer serialization speed was 0.48 seconds.

However, when deserializing the same objects the results were reversed. For deserialization, it appeared that Json.NET was about 41% faster than DataContractSerializer. The average JSON.NET deserialization speed was 1.27 seconds and the average DataContractSerializer deserialization speed was 2.16 seconds.

While this is a relatively basic, unscientific test that doesn’t explore all scenarios, it would appear that for basic serialization using the most popular .NET libraries, XML/SOAP is faster for serialization and JSON is faster for deserialization. It seems that there isn’t an enormous difference either way, as long as you’re working with reasonable message sizes (i.e., not 50k objects), and serialization performance should not weigh heavily on the decision about which format to use unless there are metrics specific to the chosen platform / framework / libraries.

Of course, the results could easily be different on other platforms or with other serialization libraries. For example, in the .NET Compact Framework on Windows Mobile, JSON deserialization was literally thousands of times faster than XML deserialization due to poor performance of .NET reflection on the platform.

Message Size

The amount of time it takes to send and receive data between a mobile device and a back-end web service is most heavily affected by the size of the messages. Given the verbosity of the format, SOAP-based XML messages are a much larger (after encoding) format when compared to the same message encoded with JSON. Another factor affecting web service message size is the use of gzip for compression between the web server and mobile client. Gzip is now almost universally supported by modern mobile web browsers, and after compression the XML and JSON messages are nearly the same size.

After doing some basic tests with 500 objects, again using JSON.NET and the WCF DataContractSerializer, the uncompressed size of the SOAP message was 257 kb and the size of the JSON message was 82 kb – about three times smaller. However, after applying gzip compression, the size of the SOAP message was 12.3 kb and the size of the JSON message was 12 kb – almost no difference. Furthermore, with current cellular data connections (i.e., 4G/LTE) – even a large message (300KB+ for example) can be received in less than a second on a mobile device with a good connection. It would appear that JSON only has a serious edge with regards to message size if gzip is not being used.

Another factor in mobile web services where message size comes into play would be the actual connection speed between the mobile device and the backend web server. When building enterprise web services for internal consumption on internal networks, XML/SOAP (if not binary) is often the first choice because the blazing (10Mbps+) fast network speed makes the impact of message size negligible. If a mobile app were to be only used on an internal, secure WiFi network (for example, a clinical app in a hospital setting) then XML/SOAP might be an appropriate choice.

Otherwise, one of the few other differentiators between the two formats would be the ease of use across platforms.

Client-side Consumption

One thing that SOAP/XML is actually good at is defining explicit contracts (via WSDL). This allows the service and the consumer to agree beforehand on what type of messages will be sent and received, and most service consumers will be able to automatically generate code to create service client proxies. For example, in Visual Studio (Right click > Add Service Reference), Xamarin Studio, or Eclipse, service clients can be easily created and updated via code generation if SOAP/XML is being used for the service. This allows for more rapid application development, as it’s easier to maintain service references as the service evolves during the development cycle. Mobile development platforms with this capability include Xamarin (iOS/Android/C#) and Windows Phone (i.e., the .NET-based mobile platforms). REST and JSON isn’t that much more difficult to work with on the .NET-based platforms, but I prefer to leave the client-side web service plumbing to code generation if possible.

Currently, it requires a bit more effort to consume SOAP/XML based services on iOS (using Objective-C), Android (using Java), and mobile web development platforms (i.e., JavaScript). Though there are a few (barely maintained) options for consuming services (wsdl2objc for iOS and wsdl2ksoap2 for Android), the support for SOAP-based web services doesn’t really exist on these platforms. I’d prefer to avoid maintaining a SOAP/XML client “manually” or writing the client by hand including all the parsing and other plumbing code. It’s usually pretty easy to consume SOAP services with Java as it’s just as much a standard in Java as it is in .NET, but it’s more difficult in Android due to the lack of full Java libraries. REST and JSON are generally just much easier to work with on iOS, Android, and mobile web  given the currently available tools.

Generally, REST/JSON web services are easier to work with on the client end as long as the service interface is relatively simple. On the other hand, if you have a very complex web service interface (though if this is the case, you might be doing it wrong in the first place…) with 50 different message types, nested objects and complex relationships, for example, you might be better off with the “type safety” and automatically generated service client code that can be achieved by using an XML/SOAP-based web service. Maintaining client code for a highly complex web service interface can be time consuming and error-prone.

Overview

In order to select a format for your mobile web services, a few items must be considered:

  • What existing technologies, middleware, or web service investments are already in-place?
  • What platforms will your apps be developed for?
  • What are the performance requirements for your app?
  • How complex are your web services?

In the end, the decision comes down to matching your requirements against the characteristics (performance, message size, and ease of consumption) of the available web service options:

REST/JSON

  • Faster deserialization, slower serialization (in .NET at least)
  • Smaller message size
  • Easier to consume in Objective-C, Android, and JavaScript (for mobile web apps)
  • Easier to consume for simple web services
  • Preferred choice for public-facing, external web services

SOAP/XML

  • Slower deserialization, faster serialization (in .NET at least)
  • Larger message size
  • Easier to consume in .NET-based mobile platforms (Xamarin, Windows Phone)
  • Easier to consume for highly complex web services
  • Preferred choice for private, internal web services

Your email address will not be published. Required fields are marked *

Phone: 312-602-4000
Email: marketing@westmonroepartners.com
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons