Overview

Many enterprises are creating mobile applications for their internal staff, for their customers, or both.  These applications need access to data, business rules, and business processes.  For architectural and security reasons these applications are typically built to access remotes services that provide the data and functionality that are required by the users.

Because many web applications have been built over the last decade using SOAP-based web services, many architects have made the assumption that these same SOAP-based services are the best choice for mobile applications.  We believe that the use of RESTful services, with data in JSON format is a better choice for mobile applications whether the client device technology is iOS, Android, Blackberry, or even Mobile Web.

In this article, we look at the differences between SOAP and REST for use by mobile applications, analyze typical assumptions about them, and offer an approach that is geared specifically for the unique challenges involved in building mobile applications, especially for multiple platforms.

What each of them are

Before diving into an analysis of SOAP vs. REST, it will be useful to define the terms used in the analysis.

• SOAP:  “Simple Object Access Protocol”, is a protocol specification for exchanging structured information via XML in the implementation of Web Services in computer networks
• REST:  “Representational State Transfer”, was defined by Roy Fielding.  It stresses that services can be interacted with via stateless representations of the targets of the service.  It leverages the transport layer that was implemented to support the world-wide web.
• JSON: “Javascript Object Notation”, is a lightweight text-based open standard designed for human-readable data interchange. It is derived from the JavaScript programming language for representing simple data structures and associative arrays, called objects.
• Mobile Facade:  is a service tier designed for mobile devices that puts in one place all the services required by a mobile application.  It may transform and consolidate data from other services.
• WS-Security:  is an extension to SOAP that provides security to web services.
• AJAX:  is a set of development methods and patterns that promote highly-interactive web applications by providing direct access to remote data and services directly from JavaScript running on a web page, thus bypassing the one-page-at-a-time model for accessing remote services.
• Web 2.0:  is the concept of using AJAX, JSON and other tools to make for a richer user experience on the web.
• PII: Personally identifiable information, such as social security numbers, account numbers, or HIPAA controlled information.
• Data hiding: is a technique in data communication in which key data is never transmitted, but rather maintained by reference on ther server-side.  Used to protect PII.
• Data protection: is a technique in data communication in which data is prevented from being viewed by unauthorized persons or processes.  Typically accomplished by encryption.
• Non-repudiation: is the ability to ensure that a party to a communication cannot deny the authenticity of their signature on a message that they originated.  This is typically accomplished with digital certificates.
• Authentication: is the process of determining the identity of a client using a service.
• Authorization: is the process of determining what rights and access are availabile to a client that has been authenticated.

Analysis

SOAP

What SOAP does well

SOAP is a well-known technology that has been used effectively within a SOA framework for some time.  Many enterprises have established service tiers within their IT infrastructure to offer services to diverse applications, both inside and outside the firewall. SOAP was designed to take advantage of many different types of data transport layers including synchronous HTTP/HTTPS, asynchronous queues like MQSeries™, and even over email.  This capability helps SOAP be a single solution for many heterogeneous interconnectivity problems. However, SOAP was designed before the explosion of mobile technology and mobile applications.

Problems

• Change Control – Changing services that use SOAP often means a complicated code change on the client.  When this client is a web application server, this change is not necesarily problematic, but when the SOAP client is running on a mobile device, the problem of application update dissemination arises.
• Complexity – Generating SOAP client code from WSDL’s and XSD’s can be quite complex, and in the mobile world, this complexity is magnified by the fact that many organizations must produce the same mobile application for several platforms (iOS, Android, etc).  Re-coding the complex SOAP interfaces several times can be time-consuming and error-prone.
• Re–use – For many of the same reasons mentioned in this white paper, modern Web 2.0 applications that use AJAX have adopted RESTful services via JSON as the preferred way to have web pages directly access remote services.  Opportunities for re-use thus will be limited if mobile applications use SOAP instead of REST. As application’s migrate toward HTML5 mobile web this reuse become increasingly important.

Some false assumptions abouse SOAP

• SOAP is more secure – This assumption often comes up because there are specific security methods as part of the overall SOAP specification (WS-Security).  However one must realize that the reason WS-Security was created was largely because the SOAP specification was transport-independent and no assumptions could be made about the security availabile on the transport layer.  REST assumes that the transport will be HTTP (or HTTPS) and the security mechanisms that are built-in to the protocol will be available.

• The remote device is trustworthy – SOAP-based services have historically been consumed by code running on one application server that needs services from another entity.  Typically, both ends of the service communication are running on servers that are presumed to be secure.  The SOAP message-level or transport-level security is designed to secure the requests and responses while in transit.  In the case of mobile applications, assuming the device is trustworthy is a mistake.

REST

What REST does well

• Simplicity – REST was designed to operate with thin clients, like a web browser, through all types of networking equipment, to a variety of service types (Java, .NET, PHP, Ruby, static HTTPd, etc.).  Because of this requirement for lightweight and flexible implementation, it is very simple and also very similar to the vast majority of web traffic on the Internet.
• Infrastructure friendly – Network load balancers, real-user-monitoring gear, firewalls, proxies, are all, already, optimized for RESTful traffic because they are optimized for HTTP/S traffic.
• Cacheable – Some categories of RESTful requests are well suited to caching, such as image requests, because the entire request is expressed in the URL. Network caching infrastructure, such as a CDN, can respond with a correct answer.
• Scalable – When a REST services goes by the definition, REST requests are stateless which makes these types of requests very scalable.
• Stateless or Stateful – Although The REST definition calls for stateless calls, the approach lends itself equally well to passing session data in a request header just like web browsers pass session information. Using a session context with REST calls allows the server to hold PII and just pass references or masked versions to an untrusted client.
• Efficient – While SOAP services always return XML, REST services provide flexibility in regards to the type of data returned. A REST endpoint can just as easily return a payload of XML data as a PNG image. The de facto standard for data payloads from REST services is JSON.  This is because of the AJAX heritage of REST wherein JavaScript easily consumes JSON data. Initially Android and iOS did not contain JSON parsing frameworks as part of the OS, but in later revisions that functionality has been added. JSON payloads are usually smaller than their XML counterparts; if SOAP envelope overhead is included REST+JSON payloads are dramatically smaller.

Pssst… REST does more things well, isn’t it true ?  😉

Possible Problems

• Security must be designed in – Security requires good design and discipline. Like any data protocol, REST security must be designed with the application data in mind. With mobile apps one must plan on the remote device being compromised.  One must carefully consider the data being transmitted to ensure that only the minimal amount of data is be sent to satisfy the application requirements. PII should not be sent to a mobile device unless absolutely necessary. Commands from the device should leverage information held in the server session and that data should be compared against the current context to verify semantic correctness.
• No rigid standard – It is easy for developers to “miss the point”. We have seen many service implementations that claim to be RESTful services but are nothing more than a single servlet that inspects a posted payload for the operations to perform. This is a flawed approach and obviates many of the advantages of REST. Including command parameters in the request URL provides value to the systems monitoring and managing the request, such as caching proxies and load balancers. Using the full suite of HTTP request types (GET, POST, PUT, DELETE, etc.) will naturally provide a separation of concerns in the implementation.
• Need to protect PII – Exposure of PII can happen just as easily using REST as using HTTP or SOAP.  One must be diligent to design the application and protocol so that PII is not transmitted to systems that are not trusted.

Conclusion

Which web services approach to use is a fundamental decision that can affect the success of a mobile application.  For the reasons mention in this document, we believe that RESTful services, when implemented properly offer the best combination of:

• Developer Productivity
• Performance
• Bandwidth Efficiency
• Opportunity for Security
• Robustness

Now, Keeping in view the above discussion

… to contribute to the success and timeliness of delivery of a mobile application.  I also believe that it often makes sense to organize those services into a “Mobile Facade” built using REST, and delivering data in JSON format.  The “Mobile Facade” aggregates internal service endpoints into a single contact point for the mobile application.  This facade will isolate the mobile devices from changes within the enterprise, thereby reducing the number of required mobile application updates.  The facade can also implement some business logic to aggregate multiple internal service calls into a single mobile call for the purpose of simplifying the mobile application and improving the customer experience.

References

https://www.captechconsulting.com/blog/jack-cox/soap-vs-rest-mobile-services