As companies become more interested in exposing web services to get data to mobile apps, the question always comes up – “What format should we use for the services?”. It seems like JSON is the default answer anymore – but enterprise 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 without some analysis. 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, message size, and performance.
Performance
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 49% faster when serializing 50,000 normal 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 are reversed. For deserialization, it appeared that JSON.NET was about 58% faster than DataContractSerializer. The average JSON.NET deserialization speed was 1.27 seconds and the average DataContractSerializer deserialization speed was 2.16 seconds.
It would appear that in standard .NET Framework serialization, XML/SOAP wins for serialization and JSON wins for deserialization. It seems that there isn’t a massive difference either way if you’re working with reasonable message sizes (i.e. not 50k objects), and serialization performance should not weight heavily on the decision on which format to use unless there there are metrics specific to the chosen platform / framework / libraries.
The results could easily be different on other platforms or with other serializers. Anecdotally, in the .NET Compact Framework on Windows Mobile – JSON deserialization was thousands of times faster than XML deserialization. I had an instance where deserializing around 7000 XML objects took 5+ minutes (due to poor reflection performance) and deserializing the same objects with JSON took only seconds.
Message Size
The size of the messages are important for reducing the amount of time it takes to send and receive data in your mobile app. Given the verbosity of the format, SOAP-based XML messages are much larger (after encoding) format when compared to JSON-encoded messages. However, after gzip compression (commonly available and used on most mobile web browsers and web servers), the size of the messages are usually comparable.
After doing some serialization tests with 500 objects, again using JSON.NET and the WCF DataContractSerializer – the uncompressed size of the SOAP message was 257 kb and the JSON message size was 82 kb – about three times smaller. However, after gzip compression the size of the SOAP message was 12.3 kb and the JSON message was 12 kb – almost no difference in size. Further, with current cellular data connections (i.e. 3G/4G) – even a large message (300kb+) can be received in less than a second on a mobile device with a good connection.
It would appear that JSON only has a slight edge on message size if gzip is being used, and a major edge if gzip is not being used. If the absolute best possible performance is needed for a mobile app, then I’d go with JSON – 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. 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), MonoDevelop, 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 MonoTouch (iOS/C#), Mono for Android (Android/C#), and Windows Phone 7, i.e. the .NET-based mobile platforms. REST and JSON aren’t impossible to work with on the .NET-based platforms, but I prefer to leave the client-side web service plumbing to code generation if possible.
It is usually more difficult (and there are fewer libraries available) to consume SOAP/XML based services on iOS (using Objective-C), Android (using Java), and mobile web development platforms (i.e. using jQuery mobile, SenchaTouch, etc.) – there are limited options available for automatically creating SOAP/XML service clients on these platforms (half-baked, buggy, unsupported, or not-updated-in-3-years efforts aside). I’d never want to maintain a SOAP/XML client “manually”, or write the client by hand. 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 for some reason it’s a pain in Android. REST and JSON are generally just much easier to work with on the aforementioned platforms given the currently available tools.
Overview
In the end, the decision comes down to a few things: performance and message size (with negligible impact either way), and ease of use on the mobile platform of choice… in summary:
REST/JSON
- Faster deserialization (in .NET at least)
- Smaller message size
- Easier to consume in Objective-C, Android (using Java), and JavaScript (for mobile web or cross-platform apps)
SOAP/XML
- Faster serialization (in .NET at least)
- Slightly larger message size (after compression)
- Easier to consume in .NET-based mobile platforms (MonoTouch, Mono for Android, Windows Phone 7)