What Is SOAP? Web Services Explained for API Developers (2026)

SOAP, originally called Simple Object Access Protocol, is now considered a legacy technology and has largely been superseded by REST APIs, GraphQL, and gRPC. However, SOAP is still widely deployed and is often the only way to connect to enterprise systems.

This article is for IT professionals who need to understand SOAP to integrate Web Services with modern APIs.

What Is SOAP?

Today, SOAP is often seen as an old and complicated technology. When it became popular around the turn of the millennium, however, it was quite progressive:

• Messages were human-readable and self-descriptive
• Messages were transported between organizations over the Internet
• It enabled interoperability across operating systems and programming languages
• It was much simpler than previous technologies such as CORBA, RMI, or DCOM

Soon SOAP could be found everywhere, from payment systems and telecommunications to banking, government services, and ERP integration.

SOAP is not particularly simple, not about object access, and not a standalone application protocol. The acronym is therefore no longer expanded today. SOAP is better described as a protocol framework that allows building application protocols on top of it rather than a protocol itself.

The SOAP specification defines:

• The rough structure of a message
• How messages are processed
• How messages are transported (e.g., over HTTP)

However, SOAP does not define:

• The structure of the payload inside the SOAP body
• Data types and schemas
• Operations or service interfaces
• Message exchange patterns (for example synchronous or asynchronous)
• The message style (remote procedure call or document messaging)

To describe a complete Web Service interaction, additional standards such as WSDL and XML Schema are required.

Structure of a SOAP Message

The central element of the SOAP specification is the SOAP envelope. It carries the message and consists of an optional header and a mandatory body.

SOAP messages are XML documents. The following example shows a simple SOAP message:

<s11:Envelope xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/">
    <s11:Body>
        <city:getCity xmlns:city="https://predic8.de/cities">
            <name>Delhi</name>
        </city:getCity>
    </s11:Body>
</s11:Envelope>

The elements prefixed with s11 are defined by the SOAP specification. The getCity element with the city prefix is application-specific and must be defined elsewhere, for example in a WSDL document and XML Schema.

The SOAP header is a container for technical metadata such as security credentials, session data, routing information, or transactional context.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header>
        <tx:Transaction soap:mustUnderstand="true" xmlns:tx="http://example.com/transaction">
            <tx:TransactionId>123456</tx:TransactionId>
        </tx:Transaction>
    </soap:Header>
    <soap:Body>
        ...
    </soap:Body>
</soap:Envelope>

Header entries are optional and may be processed by intermediaries such as gateways or message brokers. The mustUnderstand attribute indicates that a receiver must process the header or reject the message.

For error handling, SOAP defines a Fault element inside the body:

<s11:Envelope xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/">
  <s11:Body>
    <s11:Fault>
      <faultcode>s11:Client</faultcode>
      <faultstring>City 'Delhi' not found</faultstring>
    </s11:Fault>
  </s11:Body>
</s11:Envelope>

How Does SOAP Work?

SOAP messages are most commonly transmitted over HTTP, but they can also be sent over message queues or other transports. When HTTP is used, it determines the communication characteristics.

By combining SOAP with HTTP, you typically get Remote Procedure Call (RPC)-style communication. A client sends an HTTP request to a server, and the SOAP message is included in the HTTP body using a POST request.

POST /city-service HTTP/1.1
Host: localhost:2000
Content-Type: text/xml

<s11:Envelope xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/">
    <s11:Body>
        <city:getCity xmlns:city="https://predic8.de/cities">
            <name>Delhi</name>
        </city:getCity>
    </s11:Body>
</s11:Envelope>

The server processes the message and returns an HTTP response that also contains a SOAP message in the HTTP body:

HTTP/1.1 200 OK
Server: Membrane API Gateway
Content-Length: 285
Content-Type: text/xml

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body>
        <cs:getCityResponse xmlns:cs="https://predic8.de/cities">
            <country>India</country>
            <population>34665600</population>
        </cs:getCityResponse>
    </s:Body>
</s:Envelope>

With HTTP, the interaction follows the standard request-response model. The client sends a request, the server processes it, and returns a response. With other transports such as email or messaging systems, the exchange pattern can be different, for example asynchronous or one-way.

What Is a Web Service?

A Web Service is a network component that can be accessed over the Web by sending messages. Typically, a Web Service processes SOAP messages and exposes a contract described using the Web Services Description Language (WSDL).

Historically, the term Web Service was often used synonymously with SOAP-based services. Today, however, the term is broader and may also refer to REST-based APIs. In practice, when working with legacy enterprise systems, Web Service usually still means a SOAP service.

The Dream Team: SOAP and WSDL

SOAP alone leaves many questions unanswered. How is the content of the SOAP header and body structured? Which data types are used? What operations does a server provide, and where are the endpoints located? These questions are addressed by the WSDL standard.

WSDL describes the operations of a service, the structure of messages, the data types, and the service endpoint. It serves as input for client and server code generators that simplify the development of applications using SOAP. SOAP and WSDL complement each other. Together they provided a complete framework with strong tool support for building distributed systems.

SOAP Criticism

SOAP-based Web Services were very popular in the 2000s. On top of SOAP and WSDL, the dominant architecture at that time, Service-Oriented Architecture (SOA), introduced more and more additional standards. As a result, the technology stack became increasingly complex, with many namespaces, large WSDL files, and numerous related XML-based specifications.

Projects gradually shifted from SOAP-based Web Services to simpler REST-based APIs. These approaches were easier to understand, required less tooling, and worked more naturally with HTTP.

After around 2010, few new SOA standards emerged, and development of SOAP frameworks and toolkits slowed down. Some libraries are no longer actively maintained, and older implementations are sometimes incompatible with newer Java platform versions.

However, there are still active projects. For example, Apache CXF, an implementation of the JAX-WS and JAX-RS specifications, continues to be maintained(as of 2026).

SOAP 1.1 or 1.2? Which Version Should We Use?

The newest version is SOAP 1.2, published in 2007. At that time, SOAP was already losing popularity, and version 1.2 was never adopted as widely as version 1.1. As a result, many existing services and tools still rely on SOAP 1.1.

For maximum compatibility, it is often safer to use SOAP 1.1. If all clients and servers involved support SOAP 1.2, it can be used without issues.

Should I Still Use SOAP in 2026?

No. New services should not be designed with SOAP unless there is a very specific requirement that cannot be addressed otherwise. For most new systems, REST, gRPC, or event-driven interfaces are a better fit.

However, many existing enterprise systems still use SOAP and cannot easily be replaced or rewritten. In those cases, SOAP services must still be integrated into the API landscape and operated reliably.

API gateways, especially Java-based ones, often provide legacy integration features that help route, transform, validate, and connect SOAP clients and services with modern APIs.

Is REST a Successor of SOAP?

Many companies used SOAP in the 2000s and later moved to REST-based APIs in the 2010s and 2020s. One might therefore get the impression that REST is the successor to Web Services and SOAP. However, this is not entirely accurate.

Both approaches emerged around the same time at the turn of the millennium. SOAP gained popularity quickly, especially in enterprise environments. REST, in contrast, evolved more gradually and saw steady adoption over time, eventually becoming the dominant style for modern APIs.

WS-* Standards

A whole ecosystem of web service standards was built on top of SOAP and WSDL. Some of the more well-known ones include:

• WS-Security
• WS-Addressing
• WS-ReliableMessaging
• WS-Policy

There are several dozen WS-* specifications. However, many of them saw limited real-world adoption. In practice today, WS-Security and WS-Addressing are the ones most commonly encountered. For most integration scenarios, it is not necessary to study the broader WS-* stack in detail.

Conclusion

SOAP was a major step forward for distributed systems, although it is now considered outdated. It popularized human-readable, self-describing message formats for communication between applications.

In one aspect, SOAP still has an advantage over REST. SOAP is defined by formal standards, while REST has no single official specification and is implemented in many different ways.

API gateways with SOAP and WSDL integration support can help bridge modern API infrastructures with legacy systems.

Resources