SOAP vs REST

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.

SOAP - "Simple Object Access Protocol"

SOAP is a method of transferring messages, or small amounts of information, over the Internet. SOAP messages are formatted in XML and are typically sent using HTTP (hypertext transfer protocol).

So SOAP has a standard how a message has to be sent.

Each soap web service can be defined with a WSDL(Web Service Definition Language) which is kind of a schema for the SOAP XML transferred.

There are many tools available to convert WSDL(your webservice definition) to native code.

One of the tool available for ObjC is Sudz-C (http://sudzc.com/) which convert the WDSL of any webservice to ObjC code to access the Web service

Rest - Representational state transfer

Rest is a simple way of sending and receiving data between client and server and it don't have any much standards defined , You can send and receive data as JSON,XML or even a Text. Its Light weighted compared to SOAP.

To handle Rest in iOS there are many tools available, I would recommend RestKit http://restkit.org/, for handling XML and JSON both.

I would suggest you to go with Rest for mobile development, since its light weight 

Descriptive Things below : 

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 necessarily 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 applications 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 available 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 HTTP, 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.  

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

... to contribute to the success and timeliness of delivery of a mobile application.  We 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.