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