This content is part of the Essential Guide: Guide to enterprise mobile app development and SOA

Essential Guide

Browse Sections
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

REST or SOAP: Which offers the most benefits for mobile applications

When choosing between REST or SOAP for mobile apps, it's important to remember there are two major models: native and wrapped mobile web applications.

What is the biggest benefit of using REST instead of SOAP in mobile applications?

If you've ever read or been involved in a discussion with a true "RESTafarian," you've probably heard that representational state transfer (REST) is the architecture of the web, and there's certainly a lot of truth to that.

There is no arguing with it: REST is a very good fit for browser-based interactions. Browsers and the engines behind them are built to traverse the links in the content they process, as well as providing an array of handlers for the various response types that are possible. The dominant programming language for browsers is JavaScript and, let's face it, trying to program a simple object access protocol (SOAP) client in JavaScript is not something anyone wants to do. We've even moved away from using extensible markup language (XML) and toward Javascript object notation (JSON).

Why am I talking about web browsers when the question is about mobile applications? The reason I bring up the web browser first is two-fold.

First, there are really two major models for mobile applications: native and wrapped mobile-web. Native applications are built from the ground up using the languages, native libraries and toolkits of the mobile OS platform involved. For example, for iOS devices, it's Objective C and the libraries and toolkits provided by Apple for iOS. The presentation logic is installed on the device as part of the application installation.

Wrapped mobile web applications merely use a native component that wraps a web browser but also provides a bridge between the device capabilities and the web browser, as when interacting with the photo library of the device. The bulk of the presentation logic isn't installed with the application installation, but downloaded via the web when the application is run. When this style is used, we're back to a typical web approach using JavaScript, and SOAP simply isn't an option.

But what about native applications? Why couldn't SOAP be used? There are third party libraries for both Android and iOS that make calling SOAP Web services easier, but out of the box there isn't native support for it. This isn't terribly surprising for iOS as Objective-C has its roots in desktop programming for the Mac, and SOAP has its roots in enterprise integration. It's a bit more surprising for Android, given that Java was the first supported language for application development.

What this really comes down to is a matter of ubiquity and simplicity. First, while native platforms don't support SOAP out of the box, they do support HTTP and XML, so the ubiquity exists. On the simplicity side of things, XML is certainly better than SOAP and, in the case of wrapped mobile web applications, JavaScript is better than XML.

What this really comes down to is a matter of ubiquity and simplicity

REST isn't just about JSON or XML though, but any of the media types that the browser or platform can natively handle. If I can get back a byte stream and just hand it off the capabilities of the browser or a native presentation component, rather than having to tunnel that data through something like a SOAP envelope, things are not only simpler, but they're also going to be less processor intensive, which means better battery life for the end user.

Follow us on Twitter at @SearchSOA and like us on Facebook!

Dig Deeper on REST, SOAP and API protocols