Why SOAP? Why not HTTP?

[sriram sundararajan]

Servlet & JSP's are using HTTP protocol to send request and receive information.

Why can't use HTTP itself for web service too, why should i have to rely on SOAP?
Using web service i can transfer data from one app to other app running in two different technologies, say java app to .net app.

So why can't i use HTTP in web service, as i can send and receive information in java and .net using HTTP?

What is so speacial about SOAP, that we are using in webservice?

If encryption is the problem, i can very well use HTTPS right?

Here is what i read about SOAP, "SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages" Can't i achieve the same using HTTP?

[Jimmy Clark]

Looks like you can benefit from learning about REST web services. Good luck!

[sriram sundararajan]

Yes, for sure i have to jump into this so called ocean call webservices, SOA etc.

Using SOAP all the messages are transferred in web services, so before understanding the webservice, if i know the need, necessity, and the evolution of SOAP i can understand it even more better.

[William Brogden]

I wrote a couple of articles contrasting REST with SOAP and giving some background on both.
the REST story
the SOAP story
That site wants you to register but dont worry its painless. They just like to track users so they can get paid by advertisers and eventually pay me.

Bill

[Pat Farrell]

sriram sundararajan wrote: What is so speacial about SOAP, that we are using in webservice?

SOAP's main advantage is that it was buzzword compliant 6 or 7 years ago.

Once upon a time, iits letters stood for "Simple ... Protocol" but it was changed because it wasn't simple.

Modern systems use REST, as Bill mentioned up thread.

You can use REST to send and receive XML is you really want to.

I see no reason to use SOAP at all for new work.

[Ulf Dittmer]

It's not "SOAP vs. HTTP" - HTTP is used as the transport protocol for most web services. SOAP is the (XML-)payload that contains the web service call data.

There are various reasons still to use SOAP, especially in complex scenarios that involve multiple hosts and/or have more advanced synchronization and/or security requirements, but I agree that the majority of web services out there could be implemented using REST instead.

[Pat Farrell]

Ulf Dittmer wrote:There are various reasons still to use SOAP, especially in complex scenarios that involve multiple hosts and/or have more advanced synchronization and/or security requirements

I will grant that there may be uses for it, but IMHO, its used far more often that is justifed by real engineering reasons.

If you have "advanced synchronization" requirements, you are essentially getting into the area of "two phase commits" which while technically possible, are an operational disaster. Its better to redesign the protocol so you don't need it, rather than hoping it will work and scale and be robust

[Daniel Martins]

REST cannot fully replace SOAP.

Integration with legacy systems or communication with several intermediates are situations where REST is useless.

Both have their advantages according to the required functionality/implementation.

So it's hard to understand all of this hype on REST neglecting that it cannot fully replace SOAP.

Cheers

[Ivan Krizsan]

Hi!
Hypes come and go. I've found that the best way is to acquire thorough knowledge about the different tools. This way I am able to choose the right tool for the right job.
Knowledge is never a heavy burden and my knowledge about SOAP web services has helped me in more than one situation, despite the situation not having immediate connection to SOAP web services.
So, for the original question, my advice is to obtain some hands-on experience with both SOAP and REST web services and, yourself, determine whether which one is the best fit for a given situation.
Best wishes!

[Michael Van]

Rest is the new hotness, SOAP is old and busted, and HTTP is the van they both go to school in.