REST Vs SOAP

What is a Web Service:

Web Service is a way to communicate between applications running on different operating systems, with different technologies and may be different programming languages over the internet.

Web services are part of the Services Oriented Architecture (SOA) and are used as the model for process decomposition. 

REST Vs SOAP which one is better to use

Try SOA With REST OR SOA with SOAP : Principles

REST stands for Representational State Transfer, which is an architectural style for HTTP request based applications, it is primarily used to build Web Services that are lightweight, maintainable, and scalable. A service/API based on REST is called a RESTful service/API.

Due to simplest implementation, REST has gained widespread acceptance across the Web as a simple alternative to SOAP or WSDL-based Web services. REST is not dependent on any protocol, but almost every RESTful service uses HTTP as its underlying protocol, RESTful systems communicate over the HTTP protocol and can use all the HTTP methods like GET, POST, PUT, DELETE, etc to get/update data on server. In general these methods are used by web browsers to retrieve and send data to the remote web servers whereas SOAP uses only one method POST to get and post data which gives the advantage to pass through any proxy and firewall. While PUT and DELETE methods may be restricted by proxy or firewall.

The REST has become the default back-end implementation (web services) for most of the Web and mobile applications.

A RESTful service is stateless by nature and does not maintain the application state for any client. A request cannot be dependent on a past request and a service treats each request independently. HTTP is a stateless protocol by design so you need to use some tricks/things to implement a stateful service using HTTP.

SOAP is a well defined messaging protocol(set of rules) known as Simple Object Access Protocol, which is based on XML and facilitates communication between applications over the internet using HTTP.

The Web Services Description Language (WSDL) contains and describes the common set of rules to define the messages, bindings, operations and location of the Web service. WSDL is a sort of formal contract to define the interface that the Web service will be offering.

Multiple factors need to be considered when choosing a particular type of Web service, that is between REST and SOAP.

Web service vs Web API:

Web API is a programmatic interface to a defined request-response message system, typically expressed in JSON or XML, which is exposed via HTTP. Most of the time web APIs are considered a synonym for web services since Web 2.0 web applications have moved away from SOAP-based web services towards more cohesive collections of RESTful web resources.These RESTful web APIs are accessible via standard HTTP methods by a variety of HTTP clients including browsers and mobile devices.

Accessing an image over the web is not calling a web service but retrieving a web resources using is Universal Resource Identifier. HTML has a well-defined standard approach to serving resources to clients and does not require the use of web service in order to fulfill their request.

It is clear that Web Services (SOAP) are not the same as Web API (REST).

Now one can think of when SOAP should be used instead of REST and vice-versa based on requirement.

Web Service Design:

While choosing the Web services we need to think about the designing of clean and well defined interfaces. SOAP The Web Services Description Language (WSDL) contains and describes the common set of rules to define the messages, bindings, operations and location of the Web service. WSDL is a sort of formal contract to define the interface that the Web service offers.

SOAP requires less plumbing code than REST services design, (i.e., transactions, security, coordination, addressing, trust, etc.) Most real-world applications are not simple and support complex operations, which require conversational state and contextual information to be maintained. With the SOAP approach, developers need not worry about writing this plumbing code into the application layer themselves.

SOAP Web services (such as JAX-WS) are useful in handling asynchronous processing and invocation. SOAP supports several protocols and technologies, including WSDL, XSDs, WS-Addressing In a nutshell, when you're publishing a complex application program interface (API) to the outside world, SOAP will be more useful. But when something with a lower learning curve, and with lightweight and faster results and simple transactions (i.e., CRUD operations) is needed, you can definitely choose REST.

Tool supports:

While choosing a web service we need to also consider the tool supports available. SOAP is a standard protocol and has lots of tool support to design the service, making the request and wiving the response for example one can use SOAP UI to create SOAP request and analyze the response.

But in case of REST tool support is far behind. You have very few tools like browser and REST clients etc. REST don't have any tool to generate the stub APIs and well defined response messages. On other hand SOAP has tools to create stub code from wsdl and client can just invoke that to call a SOAP web service.

Performance and Scalibility:

If you mean the load of the server, REST has a bit better performance because it bears minimal overhead on top of HTTP. Usually SOAP brings with it a stack of different (generated) handlers and XML parsers. Anyway, the performance difference itself is not that big, but RESTful service is more easy to scale up since you don't have any server side sessions.

If you mean the performance of the network i.e. bandwidth, REST has much better performance. Basically, it's just HTTP with No overheads. So, if your service runs on top of HTTP you can't get much leaner than REST. Furthermore if you encode your representations in JSON (as opposed to XML), you'll save many more bytes and parsing of JSON is much faster than XML.

Coupling between client and server:

The main difference between SOAP and REST is the degree of coupling between client and server implementations. A SOAP client works like a custom desktop application, tightly coupled to the server. There's a rigid contract between client and server, and everything is expected to break if either side changes anything. You need constant updates following any change which is not the case with REST.

Sending and Retrieving Large Data:

REST is not a good fit for sending and retrieving the large amount of data from the server, in REST you need to use POST method to do this which is not a standard way. for example: to get item details you may have the API like ../details/{itemId} which will return the item details, what if I want to get the details of 1000 items, you can't use this API to pass thousands itemIds. To achieve this you need do multiple requests or need to define a new API like ../details/items and make a POST request to send the thousand items Ids in order to receive all items details. In other hand using SOAP you can have a single API which takes an array parameter (array of item Id) to retrieve the details. REST is faster and light weight as it means for small data transfer in request and response.

Following is the Comparison Summary which can help to take decisions.
'X' indicate supported and empty cell indicates not supported.
Buy SOA with REST : Principles

Architectural Decision	REST	SOAP
Transport Protocol
HTTP	X	X
Waka	X
TCP		X
SMTP		X
JMS		X
MQ		X
BEEP		X
IIOP		X
Payload Format
XML (SOAP)	X	X
XML (POX)	X
XML (RSS)	X
JSON	X
YAML	X
MIME	X
Service Identification
URI	X	X
WS-Addressing		X
Integration Style
Remote Procedure Call	X	X
Messaging		X

Conclusion:

In general, if you writing web services for thin clients like mobiles, TABs and PDAs then choose REST, as a REST based Web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats. SOAP is favored where service requires comprehensive support for security and transactional reliability. Like eBay provides SOAP web services for interaction and integration to eBay website.