Why is HTTP / SOAP considered fat?

Question

I heard some opinions that the SOAP / HTTP web service call stack is “fat” or “heavy”, but I can’t pinpoint why. Will this be considered fat due to serialization / deserialization of the SOAP envelope and message? Is this really a difficult operation?

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

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

Answer 1

SOAP is designed to be abstract enough to use transports other than HTTP. This means, among other things, that it does not use certain aspects of HTTP (mainly RESTful use of URLs and methods, for example PUT /customers/1234 or GET /customers/1234 ).

SOAP also bypasses existing TCP / IP mechanisms for the same reason - it is transport independent. Again, this means that it cannot take advantage of the transport, such as sequence management, flow control, service discovery (for example, accept() connection to a well-known port means that the service exists), etc.

SOAP uses XML for its entire serialization - while this means that the data is “universally readable” only with an XML parser, it introduces so many templates that you really need a SOAP parser to function efficiently. And at that moment you (as a software consumer) in any case lost the advantage of XML; who cares what the payload looks like by wire if you need libSOAP handle it anyway.

SOAP requires WSDL to describe interfaces. WSDL itself is not a problem, but it is generally touted as being more "dynamic" than it actually is. In many cases, one WSDL is created, and the producer / consumer code is automatically generated from it, and it never changes. In general, this requires many tools without actually solving the original problem (how to communicate between different servers). And since most SOAP services work through HTTP, the original problem was basically resolved for starters.

Answer 2

SOAP and WSDL are extremely complex standards that have many implementations that support different subsets of standards. SOAP does not map very well with a simple interface of external functions in the same way as XML-RPC . Instead, you should understand XML namespaces, envelopes, headers, WSDLs, XML schemas, etc., in order to create the right SOAP messages. All you have to do to call the XML-RPC service is to define the endpoint and call the method on it. For example, in Ruby:

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

In addition to XML-RPC, there are other methods that can also be much simpler and easier, such as plain XML or JSON . HTTP (often called REST , although this implies some other design considerations). The advantage of something like XML or JSON over HTTP is that it is easy to use from JavaScript, or even just a dumb web page with form submission. It can also be easily written from the command line with tools such as curl . It works with almost any language because HTTP libraries, XML libraries, and JSON libraries are available almost everywhere, and even if the JSON parser is not available, it is very easy to write.

Edit: I have to clarify what I mean by how conceptually heavyweight SOAP, as opposed to heavy weight, is in terms of the raw amount of data. I think that the raw amount of data is less important (although it can add up quickly if you need to process many small requests), and how conceptually heavy it is very important, because it means that there are many more places where something can go so where there might be incompatibility, etc.

Answer 3

I agree with the first poster, but would like to add to it. Thick and thin definition is relative. With transport such as JSON or REST, the appearance of SOAP looks heavy on the surface for hello world examples. Now, as you already know, that makes SOAP heavy, and WS 2.0 as a whole is a corporate / reliable feature. JSON is not protected in the same way as WS 2.0. I have not heard SOAP be called fat, but many non-XML nuts treat these specifications as heavy or thick. To be clear, I speak neither for nor against how both have their place. XML is more verbose and readable and therefore “thicker”. The last part is that some people consider HTTP a persistent connection protocol to be cumbersome, given new web trends like AJAX, rather than appearing on a large page. Connection overheads are large since there is no benefit.

So there is no real reason , except that someone wants to call SOAP / HTTP thick, this is all relative. Fewer standards are ideal for all scenarios. If I had to guess, some smart web developer thinks he's so smart when he talks about how XML technology thinks and how super JSON is. Everyone has a place.

Answer 4

The SOAP signal to noise ratio is too low. For a simple conversation, there is too much structural overhead with no data value; and too much explicit configuration is required (compared to implicit configuration like JSON).

It didn’t start that way, but in the end it was a child poster for what happens with a good idea when a standards committee is involved.

Answer 5

First of all, it depends a lot on how your services are implemented (i.e. you can do a lot to reduce the payload just by taking care of how your method signatures are executed).

However, not only a soap envelope, but the message itself can be much more cumbersome in xml, rather than a simplified binary format. Just choosing the right class and member names can greatly reduce it ...

Consider the following examples of serialized methods returned from methods that return a collection of material. Just choosing the right [serialization] name for classes / shells and members can go a long way in verbosity of serialized soap request / response if you return duplicate data (like lists / collections / arrays).

Short / short names:

 <?xml version="1.0" encoding="utf-8"?> <ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> <ShortIDName> <id>0</id> <name>foo 0</name> </ShortIDName> <ShortIDName> <id>1</id> <name>foo 1</name> </ShortIDName> <ShortIDName> <id>2</id> <name>foo 2</name> </ShortIDName> ... </ArrayOfShortIDName> 

Long names:

 <?xml version="1.0" encoding="utf-8"?> <ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> <ThisClassHasALongClassNameIDName> <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID> <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName> </ThisClassHasALongClassNameIDName> <ThisClassHasALongClassNameIDName> <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID> <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName> </ThisClassHasALongClassNameIDName> <ThisClassHasALongClassNameIDName> <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID> <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName> </ThisClassHasALongClassNameIDName> ... </ArrayOfThisClassHasALongClassNameIDName> 

Answer 6

1 - The XML schemas that are a key part of the WSDL specification are really, really big and complex. In practice, you, tools that make schemas such as XML XML Schema, in the design of a programming language only end up supporting part of the XML schema's capabilities.

2 - The WS- * specifications, such as WS-Security and WS-SecureConversation, are again large and complex. They are almost designed in such a way that no one will have less resources than Microsoft or IBM could fully realize them.

Answer 7

I considered it “fat” due to the relatively high overhead associated with packing and unpacking the message (serialization and deserialization).

Consider a web service with a web method called Add , which accepts two 32-bit integers. The subscriber sends two integers and receives a single integer in response. Where only 96 bits of information are actually transmitted, adding SOAP packets is likely to add about 3,000 or more additional bits in each direction. 30x magnification.

This includes the relatively poor performance associated with serializing and deserializing messages in UTF-8 (or something else) XML. Admittedly, it's pretty fast these days, but it's certainly not trivial.

Answer 8

I think, basically, that the SOAP envelope adds a lot of overhead for building a message, especially for the usual case of a simple request with several rather than deeply structured parameters. Compare this to a REST-style web service, where parameters are simply included in the URL request.

Then add to this the complexity of WSDL and typical implementations of "corporate" libraries ...