If you want to com­mu­nic­ate with other people in networks such as the Internet, you can only do it by following defined rules. In order to avoid the various computers and other network-enabled devices des­cend­ing into chaos, they must comply with a network protocol. SOAP is — alongside REST — one of the most important protocols on the Internet.

What is SOAP?

Com­mu­nic­a­tion on the Internet is prin­cip­ally based on protocols such as HTTP, HTTPS, FTP or TCP. SOAP is one of them, essential for web services which command search engines, online shopping and many other services on the Internet. SOAP is one of the protocols that make this work. It is an interface that a device can use to make use of a server’s services.

Fact

Ori­gin­ally, the name SOAP was used as an acronym for "Simple Object Access Protocol". However, since this name doesn’t really fit the protocol (it's neither simple, nor does it only access objects), SOAP is now only used as a name.

SOAP has been in use since the 1990s to enable com­mu­nic­a­tion between a client – for example, the Internet browser – and a server’s services. For this to work, the client must make requests to the API. The SOAP framework governs how these requests should appear. However — and this is a great advantage of SOAP — ap­plic­a­tion-specific data can be ac­com­mod­ated within this set of rules. This way, web services can provide diverse ap­plic­a­tions. SOAP only sets the basic rules so that they don’t all have to have the same syntax to be used as a web service.

Note

The software developer Dave Wiener created SOAP in col­lab­or­a­tion with a Microsoft team in order to create a working protocol for the Internet. Great emphasis was placed on making SOAP com­pat­ible with W3C standards. This made SOAP itself a W3C re­com­mend­a­tion.

SOAP web services - the ap­plic­a­tion areas of the protocol

SOAP then plays a role when a system needs to access another system in an orderly and limited way. Instead of just giving the re­quest­ing client complete access to the server, access can be re­stric­ted to the necessary functions using a protocol such as SOAP. With its ar­chi­tec­ture, SOAP also offers the advantage that very different systems are able to cooperate with each other: The protocol provides a framework into which the specific ap­plic­a­tion can integrate.

Various web services are based on SOAP. For example, Amazon and eBay (partially) work with the network protocol.

The SOAP structure: How the protocol works

SOAP is based on the XML In­form­a­tion Set. Also a W3C re­com­mend­a­tion, this col­lec­tion of in­form­a­tion units is necessary for an XML document that cor­res­ponds with a re­com­men­ded structure. SOAP uses this in its message structure and therefore cor­res­ponds, in principle, to an XML document.

In most cases, SOAP will also be in­teg­rated in HTTP. The transport therefore functions using the known protocol and is in­teg­rated into its structure. In practice, an HTTP message with a SOAP request looks like this:

POST /example HTTP/1.1
Host: example.org
Content-Type: text/xml; charset=utf-8
…
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
...
    <SOAP-ENV:Header>
        ...
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        ...
    </SOAP-ENV:Body>
</SOAP_ENV:Envelope>

In this example, the request starts with an HTTP header. Then the so-called SOAP envelope follows. As its name suggests, this wraps up the actual content of the message. Basic elements of SOAP are then the header and body.

  • Header: The header of the SOAP request contains metadata, for example, on the en­cryp­tion used. Its use is optional.
  • Body: The body of the message contains the actual data.

The terms used in the body ul­ti­mately have nothing to do with SOAP itself, but are entirely ap­plic­a­tion-dependent.

The protocol is often combined with the Web Services De­scrip­tion Language (WSDL). This is a de­scrip­tion language spe­cific­ally for web services, which, in turn, is platform-in­de­pend­ent. A client can use speech to recognise which services a web service offers. The client de­term­ines from the WSDL file which options it has for a SOAP request. Therefore, WSDL and SOAP together allow two different systems to com­mu­nic­ate with each other without any previous ad­just­ments.

SOAP vs. REST

SOAP and REST (the latter is actually an ar­chi­tec­ture and not a protocol) are both used for web services, but both approach the task dif­fer­ently. While SOAP is a bit older, REST (or RESTful web services) has caught up a lot and currently provides ap­prox­im­ately 70 percent of the web services available on the Internet.

Both, however, have different ad­vant­ages. For example, REST is con­sidered re­l­at­ively simple, doesn’t just work with XML, is faster, and is light­weight compared to SOAP. While REST allows a lot of freedom with regard to XML (JSON is often used) SOAP gives users a choice of protocols. Although HTTP is the most common choice, in theory SOAP works well in com­bin­a­tion with other protocols including FTP and SMTP.

SOAP also has a big security advantage: WS-Security (spe­cific­a­tions on security aspects relating to web services) is firmly anchored in the network protocol. The handling of errors is also better regulated in SOAP, as a function for request re­pe­ti­tion is directly in­teg­rated here.

Summary

Both SOAP and REST have ad­vant­ages and dis­ad­vant­ages—you can’t really say that one solution is better than the other. For sim­pli­city, however, most de­velopers resort to REST. Ul­ti­mately, the choice depends on which pro­gram­ming language you use and in which context you want to use the protocol.

Go to Main Menu