Most of the time when we are developing any functionality in our day-to-day work, we need to implement some functionality/utility. All of sudden we get to know such utilities are provided by third party libraries; which are well verified, tested and optimized. Similarly some time we have to process data or even get some processed data example: list of all products, list of customers, payment gateway integration. In such cases, we prefer to use services provided by third-party vendor or services exposed within or outside the application. Here the web service comes into the picture.
In this rapid development era, most of the organization don't prefer to build everything of their own. In the same race most of the organizations started to identify such services that can be exposed as a resource/component which can be used by multiple clients irrespective of the platform and language they have been developed. Such services are known as web services. They allow different applications to interact with each other. They can be used within or outside the application.
Roy Fielding coined a term REST in his Ph.D. dissertation  to describe an architecture style of networked systems. REST stands for Representational State Transfer.
According to Roy Fielding Representational State Transfer means:
"Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use."
REST was introduced as an architectural style for building large-scale distributed system. By "architectural style" we mean - a set of design rules that identify the kinds of components and connectors that may be used to compose a system or subsystem.
REST is the stateless client-server architecture in which resources are exposed as web service and can be identified by their URL's/URI's. By using set of remote methods client can use the resources and in return web service returns the representational state of the resource.
REST uses various standards to communicate:
This is one of the most important aspect that need to be considered while developing web service. Both REST & SOAP are used/known as Web Service. As we know, REST is an architectural style for building client-server application whereas SOAP is a protocol specification for exchanging data between two endpoints.
The difference between ReST and SOAP is -
|SOAP stands for Simple Object Access Protocol.||REST stands for Representational State Transfer.|
|SOAP is XML based messaging protocol.||REST is not a protocol but an architectural style.|
|SOAP has specifications for stateful implementation as well.||REST follows stateless model.|
|SOAP uses interfaces and named operations to expose business logic.||REST uses URI methods like GET, POST to expose resources.|
|SOAP permits only XML data format.||REST is not bounded to XML so it can use Plain text, HTML, XML, JSON.|
|SOAP defines its own security mechanism like JAAS.||REST uses security mechanism of underlying protocol.|
|Usage: Banking Application where security is a concern.||Usage : Mobile Application, Android application as it is light weighted as compared to SOAP.|
Based on following parameters one can consider whether one should use ReST or not.
REST web services are stateless. Hence, if service does not need, to maintain any state between requests at server REST can be considered.
As "GET" request can be cached to web server and intermediary proxies to improve performance which is the feature of REST-WS, this can be considered while opting to web service.
As SOAP-WS consists of additional headers & layers of SOAP elements & if it is used in mobile devices it will significantly decrease the performance. In such cases, REST can be considered.