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

Todd Biske
Todd BiskeTodd Biske

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.

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

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.

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!

View the next item in this Essential Guide: Software developers demanding resource based, RESTful APIs or view the full guide: Guide: When and how to use REST

Other Essential Guides Related to This Topic

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: