Passing XML as a parameter to a web service

Question

In an answer to another question it was mentioned that passing XML as a string parameter to a web service was bad practice. What is the reason for this?

Answer 1

I have used many web services that take simple XML values as a parameter or return them as output, so I am not sure exactly why someone would consider it to be a bad practice, but I could describe a few of the weaknesses.

The main downside that I can see to using arbitrary XML as an input parameter is that by itself it does not provide strong typing. If you are using a SOAP based web services with a WSDL that outlines the web service input and output variables then using basic XML as a variable does not give the user very much information. This is especially the case if you have a basic string input value to which you assume the user will enter XML data. A better approach is to use an XMLElement or XMLNode type instead of a standard string, so that there is at least a basic level of type checking for valid XML in the web service. The idea with SOAP and WSDL though are to create strongly typed parameters so that full objects can be passed back and forth across the wire between applications. You basically can create an object and use that as the basis for your input or output values and SOAP will handle the creation of a schema for serialization and de-serialization for you automatically.

The problem is that using complex data types can significantly increase the complexity required for calling the web service. Web services are offered in a variety of flavors from simple REST services to a complex web of WS - * protocols for strongly typed messages. Using Plain Old XML with no schema would definitely be a bad idea if you are building a Business to Business web service based on WS - *, but if you are creating a simple REST service then POX might suit your needs just fine.

Answer 2

This question is at least in part due to a comment of mine about string parameters containing XML being bad practice in web service design. Here's why:

If the web service author wanted his service to accept XML, with or without a schema, then he should have defined the parameter as being of the XML Schema type <xs:any/>. That permits an arbitrary XML element. It's possible to restrict the permitted XML by using <xs:any namespace="xml namespace" processContents="strict" />. This will restrict the XML to being from the particular namespace, and will validate the XML against schemas. The recipient of such a message will be able to process it as pure XML, or possibly as type object or XmlElement or the platform equivalent.

In contrast, if XML is passed as a string, then the recipient has to take action to turn it back into XML. This assumes that actual XML has been properly encoded into the string.

Passing a string also loses you the benefits of XML. For example, the encoded XML cannot be easily processed by XML-based tools, such as XSLT.

Answer 3

Its bad practice because it opens your web server to potential injection or XSS or URI poisoning types of attacks. Most web servers are never updated or patched even when they are identified as vulnerable to attacks.