BULLETINS

When we plan to develop a Web Services for your application the usual question that comes to your mind is whether to use SOAP or REST to implement the same. I am trying to list below some points regarding both the methodologies so that you can take the right decision yourself.
SOAP based applications are activity-oriented services which focus on the actions needed to perform rather than on the resources upon which they act. REST-style Web services are resource-oriented services which focus on distinct data objects upon which standard operations can be performed. You can identify and locate resources by a URL, and the operations that might be performed against those resources are defined by the HTTP specification.
SOAP: 
SOAP is an XML based communication protocol to exchange data between computers. SOAP is platform independent so that it can go around firewalls. SOAP based applications are designed to handle distributed computing environments. It is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors. With SOAP, requests and responses can be very well structured, and can even use a DTD.
But when compared with REST, it is more difficult and heavy-weight. It is harder to develop and requires tools.
REST:
REST stands for Representational State Transfer. REST is an architectural style which defines how Web standards, such as HTTP and URLs, are supposed to be used. It is very lightweight, and relies upon the HTTP standard to do its work. If you don't need a strict API definition, use REST instead of SOAP. You can version your API so that updates to the API do not break it for people using old versions. REST essentially requires HTTP, and is format-agnostic (meaning you can use XML, JSON, HTML, whatever).
It is much simpler to develop than SOAP and has less reliance on tools. We don’t need additional messaging layer. Data can be either strictly maintained or loosely maintained. The resource is easily called from Client side code like JavaScript. But it has the following disadvantages.
It is stateless; each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server. It does not provide any support for security, policy, reliable messaging etc. So services that have more sophisticated requirements are harder to develop. It works over HTTP transport model only. So it is not good for high performance applications.
SOAP requires greater implementation effort and understanding on the client side while HTTP based or REST based APIs require greater implementation effort on the server side. The two protocols have very different uses in the real world.
Hope the above points help you to make a good decision.