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?

  • 1
    Similar question: programmers.stackexchange.com/questions/111932/… – Gilbert Le Blanc Oct 3 '11 at 14:15
  • @Gilbert - the question mentions that already as inspiration. My take, this is more philosophical, instead of practical. What led to the invention, instead of, which should I choose. – sdg Oct 3 '11 at 14:21
  • 2
    Washing up? <G> – Loren Pechtel Oct 3 '11 at 21:58
  • 2
    A consultant somewhere used an enterprise information system that was fast and responsive, seeing their revenue evaporating, they invented a standard with brutally slow overhead to recommend to management. It has XMLs they said! XMLs are good, and enterprise! The permanent developers were powerless to resist. Now the consultant has an endless revenue stream making performance tweaks on the glacier-like ESB and the world is right again. – Affe Oct 3 '11 at 23:30

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 :-)

  • Lots of RESTful stuff was definitely used before SOAP was invented, they just called it GET and POST by and large. – Wyatt Barnett Nov 28 '12 at 12:54

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.

  • 4
    REST isn't restricted to CRUD, practically or theoretically. HATEOAS, for example, revolves around discoverable interactions/representations - infoq.com/articles/webber-rest-workflow. – FinnNk Oct 3 '11 at 8:32
  • 1
    FinnNK: Still not convinced... Sure, you can make anything a GET or PUT, but I'm not sure it's very RESTy in every case. For example, imagine a webservice that receives a list of records, merges them with existing records in the database (inserting new and updating existing records, but not deleting anything) and returns a list of all records that were not up-to-date. How to make that RESTfull? – user281377 Oct 3 '11 at 9:49
  • REST resources can be 'processing' resources as much as 'noun' resources. Here you'd expose some endpoint that accepts the update plus some sort of id - you can then query using that id to get the not-up-to-date records (and that query location itself may be discoverable via a link). That said batch update is one of classic scenarios for SOAP - use whatever's the best match is my take on it. – FinnNk Oct 3 '11 at 12:51
  • @ammoQ: One way your service would likely be done with a POST of the list of records. On the return you could, among other things, have a URL to GET that listed the out-of-date records. – sdg Oct 3 '11 at 12:58

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.


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 . . .

  • +1. Your's was the only answer that connects SOAP with it's origin - distributed computing. SOAP wasn't much about HTTP as much as it was about Application to Application talk - where beasts like CORBA failed! – Dipan Mehta Mar 14 '12 at 14:11

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.