What was SOAP invented for?

Question

This question is inspired by this one. What was the initial goal of inventing SOAP? Why was it invented when we had old kind HTTP and REST?

Answer 1

REST is not a standard, it is a (loosely defined) architecture. And it is tied to HTTP, which a lot of people in the corporate world saw as a limitation. So they thought they needed a general standard proper, which works over other transfer layers as well.

And btw SOAP was defined prior to REST (at least according to Wikipedia :-)

Answer 2

SOAP is way more suitable than plain HTTP for exchanging complex data structures. REST is by design practically restricted to CRUD operations, while SOAP allows arbitrary method calls, which may be something that cannot be pressed into the REST scheme.

Answer 3

From Wikipedia:

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. ... SOAP has three major characteristics: Extensibility (security and WS-routing are among the extensions under development), Neutrality (SOAP can be used over any transport protocol such as HTTP, SMTP or even TCP), and Independence (SOAP allows for any programming model).

SOAP is not limited to HTTP and provides for security right out of the box.

If you're using HTTP and you don't need security (your web service is open to the public), then you don't need SOAP.

Answer 4

I wasn't in the room, but I'd generally say SOAP was a very, very good idea and a very reasonable response to the other RPC options that existed in the mid to late 90s. Such as CORBA, a beast which I can't say I've had to personally deal with, but the mere mention of which can make grown men soil themselves. Options beyond CORBA were actually scarier in many cases and there was little standardization and lots of custom messaging protocols going on. Integrated systems were very, very hard stuff. There were good reasons not to rely on HTTP as a transport. In the late 90s, typical LAN speeds were 10 megabits or less, WAN speeds were oftentimes measured in baud. The entire edge caching infrastructure that does so much for REST didn't exist.

Which gets us to SOAP -- which in and of itself doesn't specify a transport medium. I believe someone managed to implement a SOAP call over carrier pigeon. Or perhaps an african swallow. In any case, it is a vastly simpler to implement messaging option than what came before. And if you had a decent SOAP toolkit, it was much, much easier to consume than anything else that had come before. And easier to make tools for. So easy that they thought they needed to extend the protocol. And that is where WS-* comes in. Which is where the wheels fell off that truck . . .

Answer 5

SOAP is a messaging protocol, which was created for the same reason any other messaging protocol has been created; to standardize the way in which object information is passed around. As the Wikipedia page states, it originated at Microsoft, and is now an open standard maintained by the W3C.

The better question is why to choose between SOAP or some XML-flavored scheme or JSON or whatever, and the answer comes down to use whatever's easiest/most practical in your particular situation.

Answer 6

In my opinion SOAP is another take at RPC. Just take a look at how do you expose WebService these days. One party marks method as WebService and the other just fetches WSDL and uses remote methods as if they were local. I'm pretty aware of all the SOAP problems, but on some level of abstraction SOAP/WS delivers on its RPC promise. Of course you can come up with an API based on REST architecture, but it will still require other party to code some bits which somehow defy RPC definition.