答案是document/literal为首选风格。soap编码风格分rpc与文档两类，核心差异在于消息体结构及解析方式；rpc风格将消息视为远程方法调用，参数结构化，适用于简单函数调用场景，但灵活性差且互操作性低，尤其rpc/encoded已基本被淘汰；文档风格则将消息体视为独立xml文档，结构由xml schema定义，常与use="literal"结合形成document/literal，具备高互操作性、灵活扩展性及清晰语义，适合文档交换场景；实际应用中应优先选择document/literal，因其符合ws-i规范、跨平台兼容性好，而rpc/literal仅作为次优选择，encoded风格应坚决避免。
SOAP编码风格主要分为两大类：RPC（远程过程调用）和文档（Document）。它们的核心差异在于SOAP消息体（
<body>）内部内容的结构方式以及接收方如何解析这些内容。简单来说，RPC风格把消息体看作是对某个远程方法的调用，参数会以结构化的方式呈现；而文档风格则将消息体视为一个独立的XML文档，其具体含义和结构完全由配套的XML Schema定义。
解决方案
要深入理解SOAP编码风格，我们首先得搞清楚几个关键属性：
style和
use。
style属性定义了整个SOAP消息的宏观结构，可以是
rpc或
document。而
use属性则决定了消息体内的XML内容是如何被序列化和反序列化的，它通常是
literal（字面量）或
encoded（编码）。
当
style="rpc"时，SOAP消息的
<body>预期包含一个以操作名命名的元素，该元素内部则包含对应方法的参数。如果
use="encoded"，那么参数会遵循SOAP 1.1 Section 5定义的编码规则进行序列化，这包括对复杂类型和引用（
href）的处理。如果
use="literal"，则参数会直接按照XML Schema的定义进行序列化，这通常意味着更强的互操作性。
当
style="document"时，SOAP消息的
<body>可以包含任何符合特定XML Schema定义的XML文档。这里通常只与
use="literal"结合使用，因为
document/encoded组合在实际中很少见，且往往会导致互操作性问题。
document/literal意味着消息体内的XML内容会严格按照其关联的XML Schema进行解析，它不预设任何方法调用的语义，而是将整个XML文档作为一个整体进行处理。
RPC编码风格具体是怎么回事？它有什么优缺点？
RPC（Remote Procedure Call）风格，顾名思义，就是将SOAP消息模拟成一个函数调用。它的核心思想是，你发送一个请求，就像在调用远程服务器上的一个方法，并传入一些参数。
工作原理： 在WSDL中，如果一个操作被定义为
style="rpc"，那么其SOAP
<body>中会包含一个与操作名同名的元素。这个元素内部，就是该操作的参数列表。
例如，一个
addNumbers的RPC风格请求可能会是这样（通常是
rpc/literal）：
<soap:Body>
<ns1:addNumbers xmlns:ns1="http://example.com/math">
<num1>10</num1>
<num2>20</num2>
</ns1:addNumbers>
</soap:Body>这里，
addNumbers就是操作名，
num1和
num2是它的参数。
优点：
- 直观性强： 对于习惯了传统编程语言中函数调用的开发者来说，RPC风格非常容易理解和使用。它直接映射了“调用方法，传递参数，获取结果”的模式。
- 工具支持： 许多早期的SOAP工具和框架在设计时就考虑了RPC风格，能自动生成客户端代码，让开发者感觉就像调用本地方法一样。
缺点：
- 灵活性受限： RPC风格的消息结构相对固定，紧密耦合于特定的操作和参数列表。当业务需求变化，需要增加或修改参数时，往往需要修改WSDL，并可能导致兼容性问题。
-
互操作性挑战： 尤其是
rpc/encoded
，由于SOAP 1.1的编码规则在不同实现之间存在细微差异和解释上的模糊，导致不同厂商的SOAP栈在处理encoded
消息时经常出现互操作性问题。这就像大家都在说同一种语言，但每个人对某些词的理解都有点偏差，沟通起来自然就麻烦了。现在，rpc/encoded
基本已经被淘汰了。 - 语义模糊： 有时，一个服务操作的语义不仅仅是简单的函数调用，它可能代表一个更复杂的业务事件或文档交换。RPC风格在这种情况下可能显得力不从心，无法清晰表达其真实意图。
那么文档（Document）编码风格又是如何工作的？它更适合哪些场景？
文档（Document）风格与RPC风格的理念完全不同。它不把SOAP消息体看作是方法调用，而是看作一个独立的、完整的XML文档。
工作原理： 在WSDL中，如果一个操作被定义为
style="document"，那么其SOAP
<body>中包含的是一个任意的XML文档。这个文档的结构完全由其引用的XML Schema定义。通常，
document风格会与
use="literal"结合，形成
document/literal。
例如，一个
OrderRequest的文档风格请求可能会是这样（
document/literal）：
<soap:Body>
<ns1:OrderRequest xmlns:ns1="http://example.com/orders">
<ns1:OrderId>12345</ns1:OrderId>
<ns1:CustomerInfo>
<ns1:Name>John Doe</ns1:Name>
<ns1:Email>john.doe@example.com</ns1:Email>
</ns1:CustomerInfo>
<ns1:Items>
<ns1:Item>
<ns1:ProductId>P001</ns1:ProductId>
<ns1:Quantity>2</ns1:Quantity>
</ns1:Item>
</ns1:Items>
</ns1:OrderRequest>
</soap:Body>这里，
OrderRequest不再是操作名，而是一个代表订单信息的完整XML文档。服务接收到这个文档后，会根据其Schema进行解析和处理。
最适合的场景：
- 文档交换： 当你的服务核心是交换结构化文档时，比如发送发票、订单、合同、报告等，文档风格是理想的选择。它天然地将整个业务实体封装在一个XML文档中。
- 松耦合和演进： 因为消息体是一个独立的XML文档，它的结构可以独立于服务操作进行演进（只要符合Schema）。这意味着你可以更灵活地修改文档结构，而不需要总是修改WSDL中关于操作参数的定义。
-
更强的互操作性：
document/literal
是SOAP Web服务的事实标准，因为它完全依赖于XML Schema来定义消息结构，而XML Schema是一个成熟且被广泛支持的标准。这大大减少了不同SOAP实现之间的兼容性问题。 -
Web服务互操作性组织（WS-I）推荐： WS-I Basic Profile明确推荐使用
document/literal
，这进一步巩固了其作为最佳实践的地位。
优点：
- 高度互操作性： 这是它最大的优势，因为基于XML Schema的定义是明确且标准化的。
- 灵活性和可扩展性： 消息体可以包含任意复杂的XML结构，方便处理各种业务场景。
- 语义清晰： 消息本身就是业务文档，其含义一目了然。
缺点：
- 初学者可能觉得不直观： 对于刚接触SOAP的开发者来说，它可能不如RPC风格那样直接映射到函数调用。你得更多地思考“发送什么文档”而不是“调用什么方法”。
- 需要良好的XML Schema设计： 要充分发挥文档风格的优势，你需要投入精力设计清晰、健壮的XML Schema。
在实际项目中，我们应该如何选择合适的SOAP编码风格？
在实际的Web服务开发和集成中，选择合适的SOAP编码风格是一个非常重要的决策，它直接影响到服务的互操作性、可维护性和未来的扩展性。
我的建议是：
-
优先选择
document/literal
：- 这是当前行业内最推荐、最广泛使用的风格。它提供了最佳的互操作性，无论是Java、.NET还是其他平台，在处理
document/literal
风格的服务时，通常都能做到无缝对接。 - 它充分利用了XML Schema的强大能力，可以对消息内容进行严格的验证，确保数据质量。
- 它更符合“面向消息”的架构理念，将业务实体作为独立文档进行交换，而不是仅仅看作方法参数。这让你的服务设计更具弹性和前瞻性。我个人在处理各种复杂的SOAP集成项目时，凡是遇到
document/literal
的服务，通常调试起来都顺利得多。
- 这是当前行业内最推荐、最广泛使用的风格。它提供了最佳的互操作性，无论是Java、.NET还是其他平台，在处理
-
如果非要用RPC风格，请选择
rpc/literal
：- 如果你真的觉得你的服务就是简单的函数调用，并且偏爱RPC的直观性，那么
rpc/literal
是一个次优的选择。它至少避免了encoded
带来的互操作性噩梦，因为它也依赖于XML Schema来定义参数结构。 - 但即便如此，也要权衡一下它的灵活性和未来扩展性，通常
document/literal
在这些方面表现更好。
- 如果你真的觉得你的服务就是简单的函数调用，并且偏爱RPC的直观性，那么
-
坚决避免
encoded
风格（rpc/encoded
或document/encoded
）：encoded
风格，特别是rpc/encoded
，是SOAP 1.1规范中一个历史遗留问题。它引入了SOAP自己的编码规则，而不是直接使用XML Schema。这导致了不同厂商实现之间的巨大差异，最终造成了严重的互操作性问题。- WS-I Basic Profile明确指出不应使用
encoded
风格。如果你遇到一个遗留系统使用了rpc/encoded
，那通常意味着你需要投入更多的时间去理解它的序列化细节，甚至可能需要进行一些定制化的处理才能成功集成。这就像是掉进了一个老旧的泥潭，每一步都得小心翼翼。
总结一下我的经验： 在设计新的SOAP服务时，几乎总是应该选择
document/literal。它不仅是标准推荐，也是实践中被证明最健壮、最易于维护和扩展的方案。只有在与现有遗留系统集成，且该系统强制要求特定风格时，才考虑其他选项，并且要做好应对潜在互操作性问题的心理准备。
