This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Maximizing enterprise mobile apps: Read more in this section
- How to avoid common mobile development pitfalls
- Choosing between REST and SOA for mobile applications
- Industry-based strategies for mobile development
Explore other sections in this guide:
- 2. - Using Mobile Backend as a Service
- 3. - HTML5 for mobile use
- 4. - What is going on with mobile apps?
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.
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
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.
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.