BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
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.
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.