SOAP编码风格有哪些？文档与RPC区别？（编码.区别.风格.文档.有哪些...）

答案是document/literal为首选风格。SOAP编码风格分RPC与文档两类，核心差异在于消息体结构及解析方式；RPC风格将消息视为远程方法调用，参数结构化，适用于简单函数调用场景，但灵活性差且互操作性低，尤其rpc/encoded已基本被淘汰；文档风格则将消息体视为独立XML文档，结构由XML Schema定义，常与use="literal"结合形成document/literal，具备高互操作性、灵活扩展性及清晰语义，适合文档交换场景；实际应用中应优先选择document/literal，因其符合WS-I规范、跨平台兼容性好，而rpc/literal仅作为次优选择，encoded风格应坚决避免。

soap编码风格有哪些？文档与rpc区别？

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
```
  的服务，通常调试起来都顺利得多。
如果非要用RPC风格，请选择
```
rpc/literal
```
：
- 如果你真的觉得你的服务就是简单的函数调用，并且偏爱RPC的直观性，那么
```
rpc/literal
```
  是一个次优的选择。它至少避免了
```
encoded
```
  带来的互操作性噩梦，因为它也依赖于XML Schema来定义参数结构。
- 但即便如此，也要权衡一下它的灵活性和未来扩展性，通常
```
document/literal
```
  在这些方面表现更好。
坚决避免
```
encoded
```
风格（
```
rpc/encoded
```
或
```
document/encoded
```
）：
- ```
encoded
```
  风格，特别是
```
rpc/encoded
```
  ，是SOAP 1.1规范中一个历史遗留问题。它引入了SOAP自己的编码规则，而不是直接使用XML Schema。这导致了不同厂商实现之间的巨大差异，最终造成了严重的互操作性问题。
- WS-I Basic Profile明确指出不应使用
```
encoded
```
  风格。如果你遇到一个遗留系统使用了
```
rpc/encoded
```
  ，那通常意味着你需要投入更多的时间去理解它的序列化细节，甚至可能需要进行一些定制化的处理才能成功集成。这就像是掉进了一个老旧的泥潭，每一步都得小心翼翼。