Difference between XML Over HTTP & SOAP Over HTTP

Question

Is SOAP over HTTP a subset of XML over HTTP since I assume SOAP also an xml that confirms to a schema (SOAP schema)? I assume XML over HTTP service can either be accessed using GET or POST method. Does SOAP over HTTP always use POST method? In case of XML over HTTP I assume the disadvantage is that schema file has to be shared with all the consumers whereas in case of SOAP over HTTP it will be a single WSDL file. Would it be possible to help in letting me know the difference and also advantage of one over the other?

Answer 1

SOAP is a specialization of XML, as it has a schema, such as http://www.xmlsoap.org/soap/envelope/, whereas XML is more general.

For using GET, you can read through this discussion: http://www.coderanch.com/t/463869/Web-Services/java/SOAP-request-HTTP, but basically SOAP is done via POST, though Axis2 appears to have support for GET, as a way to have SOAP work in a world where REST seems to rule.

And, according to this IBM article (http://www.ibm.com/developerworks/xml/library/x-tipgetr/index.html) SOAP 1.2 introduces GET.

As you mentioned, SOAP is a standard, so there are tools that can easily work with it, including dynamic client generation, as shown in this question, dynamic proxy soap web service client in java?, whansere the client generates the stubs needed upon connection.

If you use XML over http, it may be better, depending on the need, as a way to transfer data, but in the use cases I can think of it would seem better to just use JSON and REST, but, if you want to transfer XML, or send XML, then you could look at using REST.

POST would be the better option though as GET has size limitations (maximum length of HTTP GET request?), which is probably why SOAP is almost always POST.

The WSDL is not necessarily a single file, in WCF, if I remember, there are many xml files that need to be put together for the WSDL to be complete.

The advantage depends on what your use case is, but I find that use REST and allowing the user to select the type is useful as it can be trivial to switch between JSON and XML, for example, and is the better choice for XML over HTTP.

SOAP is best when integrating with older technologies as that may be all they can easily use. For example, when I have made webservices for SAP integration, it can be more work to have it not use SOAP, depending on the ability of the ABAP programmer.

You may find this question of use:

How SOAP and REST work with XML/JSON response?

and for a discussion about JSON and XML in webservices you may find this helpful:

http://digitalbazaar.com/2010/11/22/json-vs-xml/

I forgot this link, as they do a brief comparison, but in the end you can easily support both. In WCF I had a controller that had the business logic, and had to .aspx files, one for SOAP and one for REST, and some webservices supported both, as it was just a matter of handling the request and response differences. So, if you want to provide support for both, and have a business case showing it makes sense, then pick a framework that will make it easy to do.

http://digitalbazaar.com/2010/11/22/json-vs-xml/

Basically, the goal is to provide services to clients via the web. What clients are going to connect? How will the clients find it easiest to reach out? How much data is being passed in the request?

These types of questions will lead to the best solution for your needs.