All about web services ,SOAP and REST API, answers to what, why and when of SOAP & REST API web services.

A brief introduction about API's:

API is known as the Application Programming Interface and is offered by both the client and the server. In the client world, this is offered by the browser whereas in the server world it's what is provided by the web service which can either be SOAP or REST.

What are web services:

This is a broad term that tells us how the communication between two different set of devices or applications is held over the World Wide Web (WWW) and they are designed to support interoperable machine-to-machine interaction over a network.

Web services are frequently just Web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services.

This communication system can be categorized into two types: SOAP(Simple Object Access Protocol, and REST(Representational State Transfer), REST and REST are two approaches for interfacing to the web with web services.

SO WHAT IS SOAP AND REST?

1. What is SOAP? :

SOAP is a standard protocol which was designed before REST with the idea of ensuring that programs/applications built on different platforms and on different programming languages could exchange data in an easy manner. Since it's a protocol it has a set of built-in rules which increases it's complexity. However these standards also offer built-in compliances that can make it preferable for enterprise scenarios. The built-in compliance standards include security, atomicity, consistency, isolation, and durability (ACID), which is a set of properties for ensuring reliable database transactions. SOAP stands for Simple Object Access Protocol. It can also operate over various protocols such as HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer Protocol), TCP (Transmission Control Protocol) or UDP (User Datagram Protocol).

Microsoft originally developed SOAP to take the place of older technologies that dont work well on the internet such as the Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). These technologies fail because they rely on binary messaging. The XML messaging that SOAP employs works better over the internet.

SOAP has been around since late 1990's

IMPORTANT NOTICE ABOUT SOAP ?

When a request for data is sent to a SOAP API, it can be handled through any of the application layer protocols: HTTP, SMTP, TCP, and others, however once a request is received, return SOAP messages must be returned as XML documentsa markup language that is both human- and machine-readable

A completed request to a SOAP API is not cacheable by a browser, so it cannot be accessed later without resending to the API.

SOAP relies heavily on XML where by every operation the service provides is explicitly defined, along with the XML structure of the request and response for that operation.

SOAP permits processes using different operating systems like linux and windows to communicate via HTTP and it's XML

SOAP was long the standard approach to web service interfaces, although its been dominated by REST in recent years, with REST now representing more than 70% of public APIs according to Stormpath.

2.what is REST?

REST is a set of architectural principles attuned to the needs of lightweight web services and mobile applications. Because it's a set of guidelines, it leaves the implementation of these recommendations to developers. It relies on stateless communication.

REST was designed specifically for working with components such as media components, files, or even objects on a particular hardware device. A Restful service would use the normal HTTP verbs of GET, POST, PUT and DELETE for working with the required components. REST stands for Representational State Transfer

Many developers found SOAP cumbersome and hard to use. For example, working with SOAP in JavaScript means writing a ton of code to perform simple tasks because you must create the required XML structure every time.

REST usually relies on a simple URL, most web services using REST rely exclusively on using the URL approach. REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.

REST doesnt have to use XML to provide the response. You can find REST-based web services that output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS), the main point here is that you can obtain the output you need, in a form thats easy to parse within the language youre using for your application.

PRIMARY KEY DIFFERENCES BETWEEN SOAP AND REST ?

1. SOAP was originally created by Microsoft, and its been around a lot longer than REST. This gives it the advantage of being an established, legacy protocol while REST has been around for a good time now as well. Plus, it entered the scene as a way to access web services in a much simpler way than possible with SOAP by using HTTP.

2. SOAP is a protocol whereas REST is an architectural pattern.

3.SOAP stands for Simple Object Access Protocol whereas REST stands for Representational State Transfer.

1. SOAP uses service interfaces to expose its functionality to client applications while REST uses Uniform Service locators to access to the components on the hardware device.

5.SOAP needs more bandwidth for its usage whereas REST doesnt need much bandwidth.

1. SOAP only works with XML formats whereas REST work with plain text, XML, HTML and JSON.

7.SOAP cannot make use of REST since SOAP is a protocol and REST is an architectural pattern. while REST can make use of SOAP as the underlying protocol for web services, because in the end it is just an architectural pattern.

1. SOAP is a protocol and was designed with a specification. It includes a WSDL file which has the required information on what the web service does in addition to the location of the web service while REST is an Architectural style in which a web service can only be treated as a RESTful service if it follows the constraints of being: Client Server, Stateless, Cacheable, Layered System, Uniform Interface.

9.SOAP requires more bandwidth for its usage. Since SOAP Messages contain a lot of information inside of it, the amount of data transfer using SOAP is generally a lot

Example of SOAP request:

<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle=" http://www.w3.org/2001/12/soap-encoding"><soap:Body> <Demo.guru99WebService xmlns="http://tempuri.org/">   <EmployeeID>int</EmployeeID>   </Demo.guru99WebService> </soap:Body></SOAP-ENV:Envelope>

  while

REST does not need much bandwidth when requests are sent to the server. REST messages mostly just consist of JSON messages. Below is an example of a JSON message passed to a web server. You can see that the size of the message is comparatively smaller to SOAP.

Example of REST API data

{"city":"Mumbai","state":"Maharastra"}

1. SOAP can only work with XML format. As seen from SOAP messages, all data passed is in XML format while REST permits different data format such as Plain text, HTML, XML, JSON, etc. But the most preferred format for transferring data is JSON.

2. SOAP uses service interfaces to expose its functionality to client applications. In SOAP, the WSDL file provides the client with the necessary information which can be used to understand what services the web service can offer

                while

REST use Uniform Service locators to access to the components on the hardware device. For example, if there is an object which represents the data of an employee hosted on a URL as http://demo.users , the below are some of URI that can exist to access them
http://demo.users.com/students
http://demo.users.com/students/1

1. REST is very easy to understand and is extremely approachable, but does lack standards and is considered an architectural approach. while SOAP is an industry standard with a well-defined protocol and a set of well-established rules to be implemented, and it has been used in systems both big and small.

2. Works well in distributed enterprise environments (REST assumes direct point-to-point communication), it is standardized, Has built-in error handling, Provides significant pre-build extensibility in the form of the WS* standards and it is Language, platform, and transport independent (REST requires use of HTTP).

WHEN SHOULD YOU CONSIDER USING REST OVER SOAP ?

One of the most highly debatable topics is when REST should be used or when to use SOAP while designing web services. Below are some of the key factors that determine when REST should be used for web services:

1.Limited resources and bandwidth:
Since SOAP messages are heavier in content and consume a far greater bandwidth, REST should be used in instances where network bandwidth is a constraint.
2.Totally stateless operations:
If there is no need to maintain a state of information from one request to another then REST should be used. If you need a proper information flow wherein some information from one request needs to flow into another then SOAP is more suited for that purpose.

foreample:
For online purchasing site. These sites normally need the user first to add items which need to be purchased to a cart. All of the cart items are then transferred to the payment page in order to complete the purchase. This is an example of an application which needs the state feature. The state of the cart items needs to be transferred to the payment page for further processing.

3.Caching situations:
If there is a need to cache a lot of requests then REST is the perfect solution. At times, clients could request for the same resource multiple times. This can increase the number of requests which are sent to the server. By implementing a cache, the most frequent queries results can be stored in an intermediate location. So whenever the client requests for a resource, it will first check the cache. If the resources exist then, it will not proceed to the server. So caching can help in minimizing the amount of trips which are made to the web server.

4.Ease of coding:
Coding REST Services and subsequent implementation is far easier than SOAP. So if a quick win solution is required for web services, then REST is the way to go.

WHEN SHOULD YOU CONSIDER USING SOAP OVER REST ?

SOAP is fairly mature and well-defined and does come with a complete specification. The REST approach is just that, an approach and is wide open for development, so if you have the following then SOAP is a great solution:

1. Asynchronous processing and subsequent invocation:
if your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM WS-Reliable Messaging.

2.A Formal means of communication:
If both the client and server have an agreement on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction. An example is an online purchasing site in which users add items to a cart before the payment is made. Let's assume we have a web service that does the final payment. There can be a firm agreement that the web service will only accept the cart item name, unit price, and quantity. If such a scenario exists then, it's always better to use the SOAP protocol.

3.Stateful operations:
If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.

CHALLENGES IN A SOAP API :

1. WSDL file:
One of the key challenges of the SOAP API is the WSDL document itself. The WSDL document is what tells the client of all the operations that can be performed by the web service. The WSDL document will contain all information such as the data types being used in the SOAP messages and what all operations are available via the web service. The below code snippet is just part of a sample WSDL file.

                  <?xml version="1.0"?><definitions name="Tutorial"                 targetNamespace=http://demo.guru99.com/Tutorial.wsdl                 xmlns:tns=http://demo.guru99.com/Tutorial.wsdl                 xmlns:xsd1=http://demo.guru99.com/Tutorial.xsd                xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/    xmlns="http://schemas.xmlsoap.org/wsdl/">     <types>          <schema targetNamespace=http://Demo.guru99.com/Tutorial.xsd        xmlns="http://www.w3.org/2000/10/XMLSchema">        <element name="TutorialNameRequest">                <complexType>                          <all>                               <element name="TutorialName" type="string"/>                         </all>                   </complexType>            </element>         <element name="TutorialIDRequest">                <complexType>                      <all>                           <element name="TutorialID" type="number"/>                     </all>               </complexType>          </element>       </schema>  </types>    

As per the above WSDL file, we have an element called "TutorialName" which is of the type String which is part of the element TutorialNameRequest.

Now, suppose if the WSDL file were to change as per the business requirements and the TutorialName has to become TutorialDescription. This would mean that all the clients who are currently connecting to this web service would then need to make this corresponding change in their code to accommodate the change in the WSDL file.
This shows the biggest challenge of the WSDL file which is the tight contract between the client and the server and that one change could cause a large impact, on the whole, client applications.

2. Document size:
The other key challenge is the size of the SOAP messages which get transferred from the client to the server. Because of the large messages, using SOAP in places where bandwidth is a constraint can be a big issue.

CHALLENGES OF WORKING WITH REST API'S

1. Lack of Security:
REST does not impose any sort of security like SOAP. This is why REST is very appropriate for public available URL's, but when it comes down to confidential data being passed between the client and the server, REST is the worst mechanism to be used for web services.

2. Lack of state:
Most web applications require a stateful mechanism. For example, if you had a purchasing site which had the mechanism of having a shopping cart, it is required to know the number of items in the shopping cart before the actual purchase is made. Unfortunately, the burden of maintaining this state lies with the client, which just makes the client application heavier and difficult to maintain.

Conclusion

However, the good news for web developers is that both technologies are very viable in todays market. Both REST and SOAP can solve a huge number of web problems and challenges, and in many cases each can be made to do the developers bidding, which means they can work across the domain.