- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-27-2019 12:46 AM
Hi SN community,
Many times i have been asked in interviews "What is the difference between SOAP and REST web services and which one do you prefer and why?"
I just want to hear your opinion on this question, what should be the answer according to you.
Thanks!
Solved! Go to Solution.
- Labels:
-
Integrations

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-27-2019 04:17 AM
SOAP Vs. REST: Difference between Web API Services
SOAP vs. REST
Let' have a quick overview of SOAP and REST before we do a deep dive into the key differences between them.
SOAP – SOAP is a protocol which was designed before REST and came into the picture. The main idea behind designing SOAP was to ensure that programs built on different platforms and programming languages could exchange data in an easy manner.
REST – This was designed specifically for working with components such as media components, files, or even objects on a particular hardware device. Any web service that is defined on the principles of REST can be called a RestFul web service. A Restful service would use the normal HTTP verbs of GET, POST, PUT and DELETE for working with the required components.
Below are the main differences between SOAP and REST
|
|
---|---|
|
|
|
|
|
|
|
http://demo.guru99.com/Employee http://demo.guru99.com/Employee/1 |
<?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> |
{"city":"Mumbai","state":"Maharastra"} |
|
|
When to use REST and when to use 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 each technology should be used for web services REST services should be used in the following instances
-
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.
-
Statelessness – 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. We can take the example of any 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.
-
Caching – 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.
-
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.
SOAP should be used in the following instances
-
Asynchronous processing and subsequent invocation – if there is a requirement that the client needs a guaranteed level of reliability and security then the new SOAP standard of SOAP 1.2 provides a lot of additional features, especially when it comes to security.
-
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.
-
Stateful operations – if the application has a requirement that state needs to be maintained from one request to another, then the SOAP 1.2 standard provides the WS* structure to support such requirements.
SOAP vs. REST API challenges
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.
Challenges with the SOAP API
- 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.
- 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 with the REST API
- 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.
- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-27-2019 12:52 AM
hello,
SOAP:
1) uses WSDL, that contain data schema/meta data
2) understands only XML
3) can have its own functions
4) security: WS-security, SSL
REST:
1) users end points
2) understand XML/JSON
3) relies on standard set of 4-5 functions
4) security: SSL, HTTPS
REST is more secure than SOAP.
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-27-2019 04:02 AM
Hi
SOAP and REST both are Web services.
SOAP : Simple Object Access Protocol.
By using WSDL (Web Service Definition Language) we make a integrate with other tools.
It is understands XML language only
By using Basic Authentication.
REST API : It is a kind of Method to Integrate with other tools
Mainly there are four methods : PUT,PATCH,DELETE and GET methods.
It understands XML and JSON also.
Easiest way to integrate by using this with End Points.
By using BR we can run REST .
Regards
Raja

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-27-2019 04:17 AM
SOAP Vs. REST: Difference between Web API Services
SOAP vs. REST
Let' have a quick overview of SOAP and REST before we do a deep dive into the key differences between them.
SOAP – SOAP is a protocol which was designed before REST and came into the picture. The main idea behind designing SOAP was to ensure that programs built on different platforms and programming languages could exchange data in an easy manner.
REST – This was designed specifically for working with components such as media components, files, or even objects on a particular hardware device. Any web service that is defined on the principles of REST can be called a RestFul web service. A Restful service would use the normal HTTP verbs of GET, POST, PUT and DELETE for working with the required components.
Below are the main differences between SOAP and REST
|
|
---|---|
|
|
|
|
|
|
|
http://demo.guru99.com/Employee http://demo.guru99.com/Employee/1 |
<?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> |
{"city":"Mumbai","state":"Maharastra"} |
|
|
When to use REST and when to use 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 each technology should be used for web services REST services should be used in the following instances
-
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.
-
Statelessness – 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. We can take the example of any 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.
-
Caching – 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.
-
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.
SOAP should be used in the following instances
-
Asynchronous processing and subsequent invocation – if there is a requirement that the client needs a guaranteed level of reliability and security then the new SOAP standard of SOAP 1.2 provides a lot of additional features, especially when it comes to security.
-
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.
-
Stateful operations – if the application has a requirement that state needs to be maintained from one request to another, then the SOAP 1.2 standard provides the WS* structure to support such requirements.
SOAP vs. REST API challenges
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.
Challenges with the SOAP API
- 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.
- 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 with the REST API
- 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.
- 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.