Why Is HTTP/SOAP considered to be "thick"

Question

I've heard some opinions that the SOAP/HTTP web service call stack is "thick" or "heavyweight," but I can't really pinpoint why. Would it be considered thick because of the serialization/deserialization of the SOAP envelope and the message? Is that really a heavy-weight operation?

Or is it just considered "thick" compared to a raw/binary data transfer over a fixed connection?

Or is it some other reason? Can anyone shed some light on this?

Answer 1

SOAP is designed to be abstract enough to use other transports besides HTTP. That means, among other things, that it does not take advantage of certain aspects of HTTP (mostly RESTful usage of URLs and methods, e.g. PUT /customers/1234 or GET /customers/1234).

SOAP also bypasses existing TCP/IP mechanisms for the same reason - to be transport-independent. Again, this means it can't take advantage of the transport, such as sequence management, flow control, service discovery (e.g. accept()ing a connection on a well-known port means the service exists), etc.

SOAP uses XML for all of its serialization - while that means that data is "universally readable" with just an XML parser, it introduces so much boilerplate that you really need a SOAP parser in order to function efficiently. And at that point, you (as a software consumer) have lost the benefit of XML anyways; who cares what the payload looks like over the wire if you need libSOAP to handle it anyways.

SOAP requires WSDL in order to describe interfaces. The WSDL itself isn't a problem, but it tends to be advertised as much more "dynamic" than it really is. In many cases, a single WSDL is created, and producer/consumer code is auto-generated from that, and it never changes. Overall, that requires a lot of tooling around without actually solving the original problem (how to communicate between different servers) any better. And since most SOAP services run over HTTP, the original problem was already mostly solved to begin with.

Answer 2

SOAP and WSDL are extremely complicated standards, which have many implementations that support different subsets of the standards. SOAP does not map very well to a simple foreign function interface in the same way that XML-RPC does. Instead, you have to understand about XML namespaces, envelopes, headers, WSDL, XML schemas, and so on to produce correct SOAP messages. All you need to do to call an XML-RPC service is to define and endpoint and call a method on it. For example, in Ruby:

require 'xmlrpc/client'

server = XMLRPC::Client.new2("http://example.com/api")
result = server.call("add", 1, 2)

Besides XML-RPC, there are other techniques that can also be much more simple and lightweight, such as plain XML or JSON over HTTP (frequently referred to as REST, though that implies certain other design considerations). The advantage of something like XML or JSON over HTTP is that it's easy to use from JavaScript or even just a dumb web page with a form submission. It can also be scripted easily from the command line with tools like curl. It works with just about any language as HTTP libraries, XML libraries, and JSON libraries are available almost everywhere, and even if a JSON parser is not available, it is very easy to write your own.

Edit: I should clarify that I am referring to how conceptually heavyweight SOAP is, as opposed to heavy weight it is in terms of raw amount of data. I think that the raw amount of data is less important (though it adds up quick if you need to handle lots of small requests), while how conceptually heavyweight it is is quite important, because that means that there are a lot more places where something can go wrong, where there can be an incompatibility, etc.

Answer 3

I agree with the first poster, but would like to add to it. The thick and thin definition is relative. With transports like JSON or REST emerging SOAP looks heavy on the surface for "hello world" examples. Now as you might already know what makes SOAP heavy and WS 2.0 in general is the enterprise/robust features . JSON is not secure in the same way that WS 2.0 can be. I have not heard SOAP referred to as thick, but many non-XML nuts look at these specifications as heavy or thick. To be clear I am not speaking for or against either as the both have their place. XML more verbose and human readable and thus "thicker". The last piece is that some people view HTTP a persisting connection protocol to be heavy given newer web trends like AJAX rather than serving up on big page. The connection overhead is large given there is really no benefit.

In summary, no real reason other than someone wants to call SOAP/HTTP thick, it is all relative. Fewer standards are perfect and for all scenarios. If I had to guess some smart web developer thinks he is being oh so smart by talking about how think XML technologies are and how super JSON is. Each have a place.