Why use SOAP for webservices?

Question

I have read a tutorial "web-service-php-mysql-xml-json".

It seems everything is ok. But then why we should use soap for web services?

Answer 1

An important point user159088 mentions in her/his answer is "[...] you can generate clients very easily starting from the WSDL file [...]"!

I'd like to further elaborate on this:

You can use SOAP in conjunction with WSDL which is standardized what means that people who know the standard (WSDL) can learn from it what operations a webservice offers and how data is exchanged.

This knowledge can be used f.e. to create tools that generate type safe binder classes/objects out of the WSDL file. You can make use of those generated classes (to make RPCs) without manually implementing the requests and encoding/parsing of the data that is exchanged.

Whereas for REST there is no standard (like a WSDL schema) on how the exchanged data looks like. As a result you often end up parsing the data on your own.

---

A second point is that REST works mainly with the HTTP(s) protocol (it is based on it). It uses the CRUD verbs (CREATE/READ/UPDATE/DELETE) of the HTTP(s) protocol. SOAP does not rely on it and can thus be used with other protocols as well.

Answer 2

When building web services you can go two ways:

• SOAP
• REST

Most people choose the path of less resistance, which is REST. This means simplicity, ease of development, using HTTP the way it's meant to be used, make good use of cache proxies, more human readable results etc.

SOAP on the other end is more heavyweight than REST and is also backed up by a large set of specifications. But because it is more complex (SOAP used to be the acronym for Simple Object Access Protocol – which proved to be... NOT) SOAP is not liked by lots of people.

Both approaches work and both have advantages and disadvantages.

For example, SOAP can make use of any transport protocol not just HTTP(S), SOAP offers more options when security is concerned, SOAP offers reliable messaging etc etc. REST on the other hand permits many different types of data formats, REST allows better support for browsers because of the JSON format, REST has better performance etc etc etc.

I’m not going to go into more details since you can find a lot of comparisons SOAP vs REST on the web. The thing that I want to emphasize is the fact that in some cases one works better than the other and it is up to you to determine and choose which one to implement given your particular case.

EDIT: To answer your question:

why use SOAP or REST? we can have web service without them?

Well, the W3C defines a web service as "a software system designed to support interoperable machine-to-machine interaction over a network".

OK... that's nice for a definition. But this is not the definition for SOAP/REST, this requirement can be successfully thrown at a communication protocol to handle.

So basically you could have a web service using whatever communication protocol you want (even creating your own) as long as is supports the "interoperable machine-to-machine interaction". This also means something else than SOAP or REST (OK... REST is not a protocol, I just use it here as reference to prove my point... so bear with me).

But you create a web service because you want some clients to use your service. And your clients are out there in the wild wild west (i.e. the web :D) and people there speak SOAP/REST. An there you come and say: "We relly don't like SOAP and REST here in our shop, we like stuff like RPC, CORBA and our own unique creation the "Bone Crusher 10000" protocol. If you want to do business with us, you go learn the "Bone Crusher 10000"". And your clients will say (eyebrow raised) "Yeaaaaah righttttt.....".

(I'm assuming here that your protocol won't be something ground shacking that will totally outclass SOAP/REST :D)

So, if you don't use SOAP/REST you will limit your target audience. It's like English for example. I'm not a native English speaker, are you? Well, it does not really matter since we are able to communicate in English. Want to try this in Icelandic? . Will you wait for me while I learn Icelandic, cause that's not my native language either?

As I already said, it is up to you to determine and choose what to implement given your particular case, but if you move away from known technology stacks you throw away what comes with that: lots of experience, resources, tools and communication options.

As a closing example, there's a lot of support for the SOAP protocol today and you can generate clients very easily starting from the WSDL file. And presto... your clients can communicate with your web service. Will it go as easy as this with "Bone Crusher 10000"? If you write the tools, provide the resources, support etc... Yes! But that will cost you time and money to create something that was already invented and is in wide use today.