SOAP with Attachments (SwA) 是什么

SOAP with Attachments（SwA）是一种用MIME multipart/related包装SOAP消息与二进制附件的约定，避免Base64编码导致的体积膨胀和解析开销，但因互操作性差、生态支持弱，已被MTOM和REST替代。

SwA 的 HTTP 请求长什么样？

关键点是：Content-Type: multipart/related + start 参数指向 SOAP part，每个 part 有独立 Content-ID：

POST /service HTTP/1.1
Content-Type: multipart/related; type="text/xml"; start=""
Content-Length: ...

--boundary_123
Content-ID: 
Content-Type: text/xml



  
    
      
    
  


--boundary_123
Content-ID: 
Content-Type: application/pdf

%PDF-1.4...（原始 PDF 二进制字节，无编码）

• start 必须匹配第一个 part 的 Content-ID（含尖括号）
• href="cid:xxx" 中的 xxx 必须与目标 part 的 Content-ID 值严格一致（包括尖括号）
• 附件内容**不能做 Base64 编码**——这是 SwA 相比纯 XML Base64 的最大优势
• 多数现代 HTTP 客户端（如 Python requests、Node.js node-fetch）默认不生成这种结构，需手动构造 multipart body

为什么 SwA 几乎没人用了？

不是它设计得不好，而是生态和规范演进淘汰了它：

LTX Studio

Lightricks推出的生成式AI视频制作平台，可以根据用户输入的文本生成超过25秒的微电影视频，

下载

• .NET Framework 2.0+ 完全不支持 SwA，只支持 MTOM；Java Axis2 默认关掉 SwA，需显式启用且易出错
• WSDL 1.1 的 document/literal 绑定与 SwA 不兼容——而 document/literal 已成事实标准
• SwA 没定义如何处理多个附件、附件元数据、错误时的附件清理等边界问题，各实现五花八门
• W3C 正式推荐 MTOM（基于 XOP）替代 SwA，它保留了“不 Base64 编码”的核心优势，但通过标准化的 xop:Include 元素 + 更健壮的 MIME 规则解决了互操作性问题

你今天该用什么？MTOM 还是直接绕过 SOAP？

除非对接遗留系统明确要求 SwA，否则不要主动选它：

• 新服务优先用 MTOM：主流框架（Java CXF/JAX-WS、.NET WCF、Python Zeep）都原生支持，WSDL 可自动生成，Content-Transfer-Encoding: binary + xop:Include 更可靠
• 如果只是传文件，考虑放弃 SOAP 全流程：用 REST + multipart/form-data（如 curl -F "file=@report.pdf" https://api.example.com/upload），更轻量、调试直观、工具链成熟
• 若必须用 SwA（比如老 IBM DataPower 或 WebSphere 配置），注意：HTTP 节点需开启 MIME 解析，且不能用通用 XML 解析器直接读 Body——必须先按 multipart/related 拆包，再分别处理 XML part 和附件 part