接受和返回XML文档的Web服务-为什么？

Question

编写一个web服务接口，其方法都接受并返回XML文档，而不是更常见的本机类型和类的参数列表，有什么好处吗？

我们有一些现有的web服务就是这样设计的。传递给它们的方法的XML文档通常很大(例如，它们包含大约100条与方法调用相关的数据)。我们有用于验证XML文档的XSD文件，但总体客户端开发人员体验很差，速度很慢。当然，最好是有一个强类型的接口？

web服务是用C#编写的，客户端也是用C#编写的(我们的一些业务合作伙伴使用Java语言)。

Answer 1

如果您绝对确定您的最终用户/客户端技术是什么(例如，纯.NET和Java，其中的特性集可能是最丰富的)，那么一定要继续，并在可用的情况下利用强类型接口。但如果你的客户群是Perl、PHP、ASP、Python等的混合包，那么我会让这些人的生活变得简单和容易理解。

我们有许多web服务必须被这种混杂的客户使用，虽然我很乐意让我们的生活变得简单，但我们必须简化一点，以确保最大限度的互操作性。

Answer 2

另一个原因是某些非常复杂的XML文档可以表示为类，但这会很笨拙。具有许多重复元素的深度嵌套文档，例如：doc.a[3].b.c[4].d[52].e，很快就会让人厌烦。

此外，请记住，并不是所有的XML模式构造都可以直接转换为类。他们不是故意的。被构建为XML而不是类型的XML Schema很可能根本不会转换为类。

Answer 3

有几个原因，以及一些相关的想法：

• Interoperability.它当然可以通过一些粗糙的边缘来加快速度，但是如果你坚持使用简单的类，你应该不会有问题。也有可能首先使用契约，但您必须再次了解限制，在某些情况下类生成器不能很好地工作:(。但即便如此，您也可以将该部分作为XML加载，而不是将其全部加载。
• 您希望使用它来处理不同类型的消息。这些消息甚至可能是聚合的。但这并不是唯一的解决方案，因为只要在定义上做一点工作，你就可以将这些场景输入到键入的消息中。
• 它不需要理解所有涉及的部分，只需将适当的部分发送到适当的系统。这篇文章很有说服力，但即便如此，我也不认为不考虑如何聚合不同系统的xsd并将它们整合到您的web服务定义中是合理的。这可能无论如何都需要完成。

在互操作性方面，请注意，您可以坚持使用简单模式，并仍然将其键入。如果这是您不需要放松对富客户端的支持的问题，那么它对简单模式的支持是最好的。这些就是您想要用于某些语言的模式类型。