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
SOAP's signal-to-noise ratio is too low. For a simple conversation there's too much structural overhead with no data value; and there's too much explicit configuration required (as compared to implicit configuration, like JSON).
It didn't start out that way, but it ended up being a poster-child for what happens to a good idea when a standards committee gets involved.
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.