SOAP vs REST Web Services

SOAP stands for Simple Object Access Protocol. 

REST stands for Representational State Transfer.(Means the state can be transferred from Service Consumer to Service Provider or from backend to the UI)

SOAP is a XML based messaging protocol and REST is not a protocol but an architectural style.

SOAP has a standard specification but there is none for REST.

REST has no WSDL interface definition

REST is over HTTP, but SOAP can be over any transport protocols such HTTP, FTP, STMP, JMS etc.

WSDL is an XML-based language for describing Web services and how to access them. will run on SMTP,HTTP,FTP etc. 

The basic structure of SOAP is like any other message format (including HTML itself): header and body. In SOAP 1.2 this would look something like

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

 <env:Header>

     <!-- Header information here -->

 </env:Header>

 <env:Body>

    <!-- Body or "Payload" here, a Fault if error happened -->

 </env:Body>

</env:Envelope>

In Soap its overhead to have envelope, Header and Body apart from the messaged while in the Rest there is only messages

Header is an important part from security point of view that we can introduce Username and Password in the header part to protect from unauthorized access.

In Rest there is no inbuilt support for Security and Transaction management you have to come up with your implementation.

https://www.youtube.com/watch?v=FoHxr0R9D7U

Rest Uses all the functions supported by HTTP i.e. Post,Get,Update, Delete

The best part of the Rest Api is that we can access them using URL through HTTP.

REST has better performance and scalability. REST reads can be cached so better performance as the request will not have to go to server infact it can be read from the cache without interfering the server again, SOAP based reads cannot be cached. 

SOAP has formal WSDL Definition

REST does have any formal definition

REST can be implemented using XML and JSON(Java Script Object Notation)

REST is mostly used for CRUD operations

Create-POST Request

Retrieve- GET Request

Update- PUT Request

Delete-Delete RequestREST is a very good fit for browser-based interactions.REST can easily handle more complex requests, including multiple parameters. In most cases, you'll just use HTTP GET parameters in the URL.

The main advantages of REST web services are:

• Lightweight - not a lot of extra xml markup
• Human Readable Results
• Easy to build - no toolkits required
• We have Uniform interface for all the functions i.e. Post,Get,Delete,Put.
  Once we have developed this part we are done we can use it anywhere for any domain.
• Rest Services are scalable means when the load on the site increases we can set up clusters and service can take the load.

SOAP also has some advantages:

• Easy to consume - sometimes
• Rigid - type checking, adheres to a contract
• Development tools
  
  Most of the Big IT giants are using REST
  
  The Google Glass API, known as "Mirror API", is a pure REST API
  Twitter has a REST API
  Flickr and Amazon are also using REST
  
  What is stateful and stateless
  
   there are two primary conditions:
  • stateless
  • stateful
  These terms are used to identify the active or runtime condition of a service as it relates to the processing required to carry out a specific task. When automating a particular task, the service is required to process data specific to that task. We can refer to this information as state data.
  A service can be active but may not be engaged in the processing of state data. In this idle condition, the service is considered to be stateless. As you may have guessed, a service that is actively processing or retaining state data is classified as being stateful.
  A classic example of statelessness is the use of the HTTP protocol. When a browser requests a Web page from a Web server, the Web server responds by delivering the content and then returning to a stateless condition wherein it retains no further memory of the browser or the request
  
  "Stateful" means that the server stores information about the client and uses that information over a series of requests.
  Stateless
  When you open a web page in the browser, you will act as a service consumer and the www server will act as a service provider to serve you with a webpage. If it is a normal connection, the client and the server will both perform a handshake and initiate a session (called a TCP connection).
  After that, based on the server's and client's behavior, the state will change to either ESTABLISHED, IDLE, TIMEOUT, etc. But in REST, we are using the HTTP protocol which is a stateless, meaning the server will not store any session information about the client. The client is responsible for sending all of the details required by the server to get serviced
  State Transfer
  Using the same example, when you open a web page using some URL to view an image file (RESOURCE) on the server,the www server will show you (the client) the image in some format i.e a REPRESENTATION of the RESOURCE (image file).
  During this process, the constant resource state of the server (i.e. the state of the image file which is stored in the server database) will be represented to client in an understandable format i.e. application state of the client. So, the resource state will remain constant in respect to clients, and only the representation of the resource will change, which in turn would change the application state.
  Finally, the representation of the resource (how the image is displayed to the client), which implicitly changes the state of both the server and the client is called REST.

Stateless = like ordering pizza each time with full details (address, toppings, payment) — server doesn’t remember previous orders.

Server doesn’t remember previous requests.

• Pros:

  • Easier to scale: any server can handle any request.

  • No session storage needed on server.

Stateful = like ordering pizza and the shop remembering you and your past orders — easier for repeat orders but needs storage

Stateful (SOAP or traditional web apps)

• Server remembers the client’s session:

  • Example: user logs in, server stores session in memory.

  • Next request relies on that stored session.

• Cons:

  • Harder to scale, because each server needs session info.

  • Session storage consumes memory.