I'm not here to teach anyone to write a SOAP Web Service or a REST API. And I don't own the truth, I'm just exposing my own opinion based on my experience.
The Concept
In a simple way to understand the concept, we can assume Web Services as pieces of software running under a application server, responsible for synchronous communication.Along with JMS, it's heavily used on systems integration. One thing that must be clear is that Web Services and SOA are not the same thing. SOA is the architecture that makes use of services. And these services can or cannot be web services. The umbrella for services on the SOA concept is wider than the single idea of a web service.
SOAP x REST API
When we talk about web services, we always gets into a discussion about SOAP Web Services versus the REST API, their differences, and when to adopt each one.
SOAP is the communication protocol that runs over HTTP that makes use of a XML document that describes the methods and parameters used by the web service. This document is known as the WSDL file, and it's basically the contract between the web service and the client.When we read and learn about SOAP, the UDDI is always mentioned. UDDI can be seen as a catalog of web services. But I've never seen an UDDI fully implemented and in use.
The Java specification in this case is the JAX-WS - JSR 224.
On REST, instead of having a contract, you make use of URLs and verbs (GET, POST, PUT and DELETE), just like HTTP, to pass information to the client. This information doesn't have to be an XML document. Can be anything else, like a JSON document.The Java specification in this case is the JAX-RS - JSR 339.
When to use them? Some may say it's a really abstract question, since both can solve the same problems. But you can find some differences when you think about their nature. Imagine a Bank, that needs to be integrated to external companies. The systems are exposed to their partners as web services. In this scenario, it's interesting to have a well defined document/contract for the communication, to make sure the correct information is being sent/received. I believe that's the reason SOAP the most used protocol on the integration scenarios. Even though you can use REST with a XML being communicated and validated agains an XSD, for example, on SOAP, this contract is more consistent.
In another hand, for a product developed by one company, exposed over the internet, it will make calls to their own systems. Lighter and with higher performance, REST looks like to be the best option on this scenario.
Some Testing Tools
soapUIcURL
