This is drafted post. Please setdraft: falsein this .mdx file once ready to be published.

What are SOAP APIs and How to create a SOAP API?

4 Min Read

Vyom Srivastava

What is SOAP API?

SOAP is an acronym for Simple Object Access Protocol. It is an XML based messaging protocol for accessing information between two platforms. SOAP is an application of XML specification. It is a communication model that communicates through the internet. It was designed in 1988 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghose. Initially, it was designed for Microsoft and transmitted data over HTTP/HTTPS. Unlike REST APIs, SOAP APIs support XML data format only.

SOAP can extend HTTP for messaging service and provides data transport for web services. It can be used to exchange complete documents or call a remote procedure which later can be used to broadcast a message. One of the major advantages of SOAP is that it is language and platform-independent. With SOAP services, the clients can easily connect to a remote service and invoke processes.

SOAP has been a popular messaging protocol since the early 2000s. It uses XML as the format and a well-defined schema and your choice of the transfer protocol. It can be HTTP/HTTPS or TCP or SMTP etc. Despite its popularity, people are moving towards REST APIs.

History of SOAP and why people shifted towards REST APIs?

Let’s go way back to the 90s, people were writing their softwares and there wasn’t any concept of networking at that time. So that software was sitting in the same box or machine. They would call a method/function in the same machine to run the software. This worked as an RPC or Remote Procedure Call which will call a method on the network. At that time, developers have been creating protocols that worked on their network only, there wasn’t any standard at that time.

Then, SOAP was introduced with some standards like using only XML as a universal data format to transfer the data. Why was XML used? Because it is Extendible and we can make it flexible enough so that we can write our message in this schema. Now developers had one data format which can be accessed on any network through the internet. So if a client is connected to a SOAP API, the server knows what will be the schema of the XML as it is being already defined. Being connected to HTTP/HTTPS, TCP, SMTP it could be connected from almost any network as at that time these transfer protocols were very popular.

So now what happened was, the XML became very rigid. By rigid I mean, the client had to create the XML in the same format so that it could be understood by the servers.

XML and HTML both are markup languages, right? But do you know what’s the difference? In HTML, the tags are predefined. This means the browser can only understand a specific set of HTML tags. While in XML, you can define your tags. Your application can extend those messages, you’re not bound to a set of specific tags.

This rigid schema became a problem after some time. People had to follow the same schema, exact the same sequence. People who just wanna write and add, have to follow a specific schema which slows down the adoption rate. They wanted something more loose structure where they can just send the data like in JSON. Some people liked the schema way while some didn't. This is why developers moved towards a more open system like REST.

Another reason is the XML itself, processing the data from XML is a slow process. Due to its large size, it consumed a lot of bandwidth which resulted in more processing time.

Advantages of SOAP API

  • SOAP has a way of specifying data format in a matured form.
  • Schema, it has its pros and cons. For example, if someone sends a malformed message the server can right away discard it.
  • Being extensible, anyone can define their tags, and as long as your SOAP server can parse these tags everything will work fine.


  • SOAP is language, platform, and transport-independent while REST requires the use of HTTP/HTTPS.
  • SOAP works on Distributed Enterprise Environment while REST works on point to point communication.
  • SOAP is more standardized while REST is more of a structural way to make APIs.
  • SOAP has built-in error handling while REST doesn’t.
  • REST is easier to use, lightweight, and more flexible than the SOAP.
  • REST is cheaper than SOAP.
  • REST requires a smaller learning curve.
  • REST uses JSON which is more efficient than SOAP’s XML.

Working of SOAP API

Most of the time SOAP utilizes the HTTP request/response method to transfer the data from one point to another. The client first creates an XML request which is parsed to read the function name, parameters, and method. Once the server receives the XML it extracts all the information from the XML and returns the response to the client. In the end, the client can parse the XML and extract all information it needs. HTTP is not the only transfer protocol SOAP uses, it can also use SMTP, TCP, etc but the functioning remains the same.

Now we have covered a lot about the SOAP APIs, why not try to create one SOAP service?


  • Basics of NodeJS
  • Firecamp for API testing

Step -1: Installing the dependencies:

Open your terminal and create a folder using the below command and then open it:

mkdir soapnode
cd soapnode

Now let’s initialize our project using the command:

npm init

Once everything is done, let’s install all the packages that are required to make our SOAP web service. On your terminal run the below commands:

npm i express
npm i soap

This will install two packages express which will be used to create our server and soap which will help our API to parse the XML.

Step -2: WSDL Setup:

Now we’ll create an XML data file which will contain some data. This data will be transferred through the API. So create a file myservice.wsdl and paste the below code:

<definitions name = "MyService"
targetNamespace = ""
xmlns = ""
xmlns:soap = ""
xmlns:tns = ""
xmlns:xsd = "">
<message name = "MyFunctionRequest">
<part name = "testParam" type = "xsd:string"/>
<message name = "MyFunctionResponse">
<part name = "status" type = "xsd:string"/>
<portType name = "MyPort">
<operation name = "MyFunction">
<input message = "tns:MyFunctionRequest"/>
<output message = "tns:MyFunctionResponse"/>
<binding name = "MyFunction_Binding" type = "tns:MyPort">
<soap:binding style = "rpc"
transport = ""/>
<operation name = "MyFunction">
<soap:operation soapAction = "MyFunction"/>
<soap:body encodingStyle = "" namespace = "urn:examples:MyService" use = "encoded"/>
<soap:body encodingStyle = "" namespace = "urn:examples:MyService" use = "encoded"/>
<service name = "MyService">
<documentation>WSDL File for MyService</documentation>
<port binding = "tns:MyFunction_Binding" name = "MyPort">
location = "" />

Step -3: Creating the server and endpoints

Create a file api.js and paste the below code:

var xml = require("fs").readFileSync("myservice.wsdl", "utf8")
// var app = require('express')();
var soap = require("soap")
var http = require("http")
//http server example
var server = http.createServer(function (request, response) {
response.end("404: Not Found: " + request.url)
soap.listen(server, "/wsdl", myService, xml)
var app = require("express")()
var bodyParser = require("body-parser")
var myService = {
MyService: {
MyPort: {
MyFunction: function (args) {
return {
// This is how to define an asynchronous function.
MyAsyncFunction: function (args, callback) {
// do some work
// This is how to receive incoming headers
HeadersAwareFunction: function (args, cb, headers) {
return {
name: headers.Token,
// You can also inspect the original `req`
reallyDetailedFunction: function (args, cb, headers, req) {
"SOAP `reallyDetailedFunction` request from " +
return {
name: headers.Token,
//body parser middleware are supported (optional)
type: function () {
return true
limit: "5mb",
app.listen(8001, function () {
//Note: /wsdl route will be handled by soap module
//and all other routes & middleware will continue to work
soap.listen(app, "/wsdl", myService, xml)

Code Explanation:

We have created a variable that will store the data of our XML file. Then we have created an HTTP server to listen to port 8000. After that, we have created an endpoint /wsdl to listen and return the XML data.

After that, once the server receives a request from the client, it parses the XML using body-parser and returns the XML data.

Step -4: Testing the API

Now run the command node api.js and then open the Firecamp app and select HTTP from the main menu. Now make a GET request on the URL: http://localhost:8000/wsdl?wsdl and you’ll get the XML data:


Final Words

SOAP used to be a popular choice amongst developers in the 1990s-2000s. But dependency on XML makes this API difficult to adopt. While the REST APIs is much more flexible in nature and widely accepted by the developers. Almost 80% of the APIs are REST API. So, it’s up to you if you want to go for REST or SOAP.

What is SOAP API?History of SOAP and why people shifted towards REST APIs?Advantages of SOAP APIREST VS SOAPWorking of SOAP APIPrerequisitesStep -1: Installing the dependencies:Step -2: WSDL Setup:Step -3: Creating the server and endpointsStep -4: Testing the APIFinal Words


DownloadDocChange LogsCookiesTerms & ConditionsPrivacy PolicyContact Us

Apps & Integrations


Firecamp Newsletter