SOAP是什么如何用XML构建Web服务消息_技术教程

SOAP是用XML定义的标准化消息协议，核心结构为Envelope、Header、Body三要素缺一不可，严格依赖命名空间、层级和编码规范，手写XML有助于排查生成器无法覆盖的底层兼容性问题。

SOAP 是一种用 XML 写成的、有固定结构的网络消息协议，不是“一种 Web 服务”，而是“怎么把 Web 服务调用打包成消息”的标准方式。它靠 Envelope、Header、Body 这三块强制结构保证不同系统能统一解析——不是靠人读得懂，

而是靠机器按规则校验。

SOAP 消息必须长这样：三要素缺一不可

一个合法的 SOAP 请求 XML 不是随便套个 soap:Envelope 标签就行，命名空间、嵌套层级、甚至是否带 XML 声明都有硬性限制：

Envelope 必须是根元素，且声明 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" —— 错写成 http://www.w3.org/2003/05/soap-envelope（SOAP 1.2）会导致 .NET 客户端直接拒绝解析
Header 可省略，但一旦出现，所有中间节点（比如 API 网关）若看到 mustUnderstand="1" 属性却无法处理，就必须返回 Fault 中断流程
Body 内不能直接放业务数据，必须包裹在服务定义的操作名标签里，例如 GetUserRequest，且该标签需声明业务命名空间（如 xmlns="http://example.com/user"），否则 Java JAX-WS 会反序列化失败
严禁出现处理指令或 DTD 声明 —— 即使工具自动生成了，也得手动删掉，否则 Axis2 报错 org.xml.sax.SAXParseException: Content is not allowed in prolog

手写 SOAP XML 的典型错误场景

很多开发者以为“照着 WSDL 改几个值就行”，结果卡在 HTTP 200 但 Body 返回空或 Fault。常见原因：

WSDL 里定义的是 tns:UserId，你写了 UserId —— 缺少命名空间前缀，服务端当成未知字段丢弃
参数类型是 xsd:dateTime，你传了 "2026-01-14"（没带时间+时区），Java CXF 直接抛 XMLGregorianCalendar 解析异常
HTTP Header 没设 Content-Type: text/xml; charset=utf-8，或漏了 SOAPAction（老式 ASP.NET ASMX 服务强制要求）
用 Python requests.post() 发送时，把 XML 当字符串传给 data=，却忘了加 headers={"Content-Type": "text/xml"}，导致服务端当普通表单处理

用 Python requests 手动发一个可用的 SOAP 请求

不依赖 zeep 或 suds，只用最简依赖验证通路是否跑通（调试阶段极有用）：

发送代码：

import requests
url = "https://www./link/8aecd51d6d87cc8f1ceed1134cc06934"
headers = {
"Content-Type": "text/xml; charset=utf-8",
"SOAPAction": '"https://www./link/52d4d7e63ba0b34da02046be3a5ab5d3"'  # 注意引号和动作URI
}
response = requests.post(url, data=soap_xml_string.encode("utf-8"), headers=headers)
print(response.status_code)
print(response.text)  # 查看原始响应，别急着 xml.etree.ElementTree 解析

为什么现在还值得学手写 SOAP XML？

因为真实故障往往发生在生成器“看不见”的地方：

WSDL 自动生成的客户端把 xs:decimal 转成 Python float，精度丢失后银行系统拒收；手写 XML 可控地传 "123.4500" 字符串
网关需要在 Header 插入 WS-Security 时间戳和签名，zeep 默认不支持，必须手动拼接
某政务系统要求 Body 内操作名首字母小写（getUserRequest），但 WSDL 工具一律转大写，只能绕过代理手写

真正难的从来不是语法，而是服务端对 XML 结构、命名空间、编码细节的隐式要求——这些只在你亲手构造并逐字比对响应时才会暴露。