SOAP vs REST

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.

False Assumptions

• 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.

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.  

• REST security is transport dependent while SOAP security is not.
• REST inherits security measures from the underlying transport while SOAP defines its own via WS-Security.
• When we talk about REST, over HTTP - all security measures applied HTTP are inherited and this is known as transport level security.
• Transport level security, secures your message only while its on the wire - as soon as it leaves the wire, the message is no more secured.
• But, with WS-Security, its message level security - even though the message leaves the transport channel it will be still protected. Also - with message level security you can partly encrypt the message [not the entire message, but only the parts you want] - but with transport level security you can't do it.
• WS-Security has measures for authentication, integrity, confidentiality and non-repudiation while SSL doesn't support non repudiation [with 2-legged OAuth it does].
• In performance-wise SSL is very much faster than WS-Security.