SOAP的全称是Simple Object Access Protocol，中文常译作简单对象访问协议。虽然名称里有简单二字，但它依靠XML承载消息、强调自描述和平台无关性，在金融、电信、企业资源计划等系统中仍然保留着大量存量接口。SOAP协议的版本并不复杂，公开标准中主要分为SOAP 1.1与SOAP 1.2，早期也曾出现过SOAP 1.0草案。很多资料会把SOAP 1.2统称为最新版本，实际上W3C在2007年发布的SOAP Version 1.2第二版仍然是当前推荐标准，并没有后续的1.3或2.0版本。
理解SOAP版本不能只看版本号高低，还要结合命名空间、Content-Type、错误处理机制以及底层传输绑定来判断。真正影响开发的是协议细节差异，而不是简单记住一个数字。下面从版本演进、核心区别、迁移实践和版本识别几个角度展开说明。
SOAP协议版本演进与标准化背景
SOAP最初并不是W3C从零设计的标准。1998年前后，微软、DevelopMentor和UserLand Software等团队为了在分布式环境中交换结构化数据，设计了一套基于XML的远程调用方案，后来被称为SOAP。早期的SOAP 1.0草案更偏向对象访问，在类型编码、数组表示等方面参考了当时的序列化思路，但草案本身并没有成为长期维护的公开规范。
2000年，SOAP 1.1被提交给W3C，成为事实上的行业标准。大量厂商在工具包和中间件中实现了SOAP 1.1，这也是今天很多遗留Web服务仍然使用它的原因。SOAP 1.1的命名空间是http://schemas.xmlsoap.org/soap/envelope/，它定义了一套可扩展的消息信封结构，包括<soap:Envelope>、<soap:Header>和<soap:Body>。不过SOAP 1.1在某些细节上不够严谨，例如错误处理元素<soap:Fault>的结构比较松散，不同实现之间容易出现互操作问题。
W3C随后成立XML Protocol工作组，对SOAP进行重新梳理，最终在2003年发布SOAP 1.2推荐标准，2007年又发布第二版修订。SOAP 1.2并不是简单的版本升级，它从设计目标上更强调与XML信息集、XML Schema以及现代Web架构的兼容性。SOAP 1.2的命名空间变为http://www.w3.org/2003/05/soap-envelope，Content-Type也改成独立的application/soap+xml。因此从报文头部就能直观区分两个版本。
SOAP 1.1与SOAP 1.2的核心差异
最明显的差异是命名空间和媒体类型。SOAP 1.1使用text/xml作为Content-Type，并且依赖SOAPAction头字段辅助路由；SOAP 1.2使用application/soap+xml，SOAPAction不再是独立头字段，而是变成Content-Type中的action参数。这个变化会影响代理、网关和旧版客户端对消息的解析方式。
SOAP 1.2在消息模型上比1.1更清晰。它基于XML信息集来描述消息内容，不再假设底层一定使用XML 1.0序列化，理论上可以支持其他序列化方案。虽然现实中绝大多数实现仍使用XML文本，但这一调整让协议本身更加抽象和严谨。错误处理方面，SOAP 1.2把<soap:Fault>的内部结构固定为<Code>、<Reason>、<Node>、<Role>和<Detail>五个子元素，其中<Code>又能表达层级化的错误码，例如env:Sender和env:Receiver。SOAP 1.1则使用faultcode、faultstring、faultactor和detail，结构相对扁平，扩展性较弱。
传输绑定上，SOAP 1.1主要描述HTTP绑定，但很多内容依赖HTTP语义。SOAP 1.2则把传输框架抽象出来，将HTTP绑定作为独立规范定义，并额外支持HTTP GET方式获取消息描述，更符合HTTP的缓存和安全模型。此外，SOAP 1.2对必须理解的Header块、角色属性、中继处理等给出了更明确规则，减少了生成端和消费端理解不一致的问题。
两个版本的SOAP报文示例对比
下面通过一个股票查询接口的HTTP请求报文，直观展示SOAP 1.1与SOAP 1.2的差异。重点观察Content-Type、SOAPAction以及<soap:Envelope>上的命名空间。
SOAP 1.1请求示例：
POST /StockQuote HTTP/1.1
Host: ipipp.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:getQuote"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getQuote xmlns="urn:example:stock">
<symbol>MSFT</symbol>
</getQuote>
</soap:Body>
</soap:Envelope>SOAP 1.2请求示例：
POST /StockQuote HTTP/1.1
Host: ipipp.com
Content-Type: application/soap+xml; charset=utf-8; action="urn:getQuote"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<getQuote xmlns="urn:example:stock">
<symbol>MSFT</symbol>
</getQuote>
</soap:Body>
</soap:Envelope>从示例可以看出，业务载荷部分没有本质变化，变化集中在传输头、命名空间和SOAPAction的传递位置。如果服务端只识别SOAP 1.1，当收到application/soap+xml的请求时，可能直接返回415 Unsupported Media Type，甚至连信封都不会解析。相反，如果客户端仍发送text/xml和SOAPAction头给只支持SOAP 1.2的新版服务，也可能被网关拦截或拒绝。
从SOAP 1.1迁移到SOAP 1.2的实践要点
迁移工作首先要确认服务端框架是否真正支持SOAP 1.2。例如Java的JAX-WS可以通过注解或配置切换版本，.NET的WCF同样可以指定绑定版本，但如果使用的是旧式ASMX服务，可能只支持SOAP 1.1。先做能力探测比盲目修改客户端更重要。
其次，迁移不能只改命名空间。以Java的JAX-WS为例，要同时调整消息工厂和绑定标识，否则仍可能生成1.1风格的消息。部分框架还会在WSDL中明确列出<soap:binding>或<soap12:binding>，通过检查WSDL绑定节点可以判断服务端实际支持的版本。客户端生成代码时，也应选择对应的绑定命名空间，而不是简单把字符串替换掉。
错误处理代码也需要同步调整。SOAP 1.1中常见的是解析faultcode和faultstring，SOAP 1.2则要解析<Code>和<Reason>。如果迁移后客户端仍按旧字段读取错误信息，虽然不会立刻报错，但可能拿不到准确的错误码，导致排障效率下降。对于同时需要兼容两种版本的网关，可以保持双版本入口分开，避免在同一路径上实现过多分支逻辑。
如何识别一个接口使用的SOAP版本
实际排查时，最快的判断方式是看HTTP请求或响应头。SOAP 1.1的Content-Type通常是text/xml，SOAP 1.2则要求application/soap+xml。不过有些旧实现可能错误地使用text/xml发送SOAP 1.2报文，或者在代理层丢失Content-Type，因此不能只依赖头部判断，还需要结合XML中的信封命名空间。
信封命名空间是更可靠的标识。出现http://schemas.xmlsoap.org/soap/envelope/即为SOAP 1.1，出现http://www.w3.org/2003/05/soap-envelope即为SOAP 1.2。如果报文里没有这些命名空间，说明可能不是标准SOAP消息，或消息被错误序列化。查看服务的WSDL文件也是常用方法，1.1绑定使用http://schemas.xmlsoap.org/wsdl/soap/，1.2绑定使用http://schemas.xmlsoap.org/wsdl/soap12/，对比后即可确认。
SOAP协议当前并没有比1.2更高的版本，因此技术选型时无需追求所谓更新版本。对于新系统，如果必须继续使用SOAP，优先选择SOAP 1.2，因为它的规范更清晰、错误结构更标准、互操作性更强。对于必须兼容遗留客户端的场景，可以保留SOAP 1.1入口，但应明确版本边界与报文差异，避免两种协议在同一接口中混用造成调试困难。