将XML作为参数传递给Web服务

Question

在回答另一个问题时，提到将XML作为字符串参数传递给Web服务是一种不好的做法。 这是什么原因呢？

Answer 1

这个问题至少部分是由于我的评论，其中包含XML的字符串参数是Web服务设计中的不良做法。 原因如下：

如果Web服务作者希望其服务接受带有或不带有模式的XML，那么他应该已将参数定义为XML Schema类型的<xs:any/> 。 这样就可以使用任意XML元素。 可以通过使用<xs:any namespace="xml namespace" processContents="strict" />来限制允许的XML。 这会将XML限制为来自特定的名称空间，并将针对模式验证XML。 此类消息的接收者将能够将其作为纯XML处理，或者可能作为类型object或XmlElement或等效的平台进行处理。

相反，如果XML作为字符串传递，则接收者必须采取行动将其转换回XML。 假设实际的XML已经正确编码到字符串中。

传递字符串也会使您失去XML的好处。 例如，编码的XML无法通过基于XML的工具（例如XSLT）轻松处理。

Answer 2

我已经使用了许多将简单XML值作为参数或将其作为输出返回的Web服务，所以我不确定为什么有人会认为它是一种不好的做法，但是我可以描述一些弱点。

我可以看到使用任意XML作为输入参数的主要缺点是它本身不提供强类型化。 如果您将基于SOAP的Web服务与WSDL一起使用，WSDL概述了Web服务的输入和输出变量，那么将基本XML用作变量不会给用户太多信息。 如果您有一个基本的字符串输入值（假定用户将输入XML数据），则尤其如此。 更好的方法是使用XMLElement或XMLNode类型而不是标准字符串，以便在Web服务中至少存在基本级别的有效XML类型检查。 但是，使用SOAP和WSDL的想法是创建强类型化的参数，以便可以在应用程序之间通过导线来回传递完整的对象。 基本上，您可以创建一个对象并将其用作输入或输出值的基础，并且SOAP将自动为您处理用于序列化和反序列化的模式的创建。

问题在于，使用复杂的数据类型会大大增加调用Web服务所需的复杂性。 从简单的REST服务到复杂的WS-*协议网络（用于强类型消息），都提供了多种Web服务 。 如果要基于WS-*构建企业对企业的Web服务，则使用不带模式的Plain Old XML绝对不是一个好主意，但是，如果要创建一个简单的REST服务，那么POX可能就可以满足您的需求。

Answer 3

这是不正确的做法，因为它会使您的Web服务器容易受到潜在的注入或XSS或URI中毒类型的攻击。 大多数Web服务器即使被确定为容易受到攻击，也永远不会更新或打补丁。