文档驱动Web服务以完整XML/JSON文档为交互单元，传递语义完整的业务文档（如订单、发票），强调“传数据”而非“调方法”，契约基于消息结构（如XSD/JSON Schema），松耦合、易演进；RPC风格则类比远程函数调用，请求指定操作名与参数，紧耦合、升级成本高。
文档驱动（document-driven）的Web服务，是指以完整、自包含的XML（或JSON等格式）文档作为请求和响应基本单元的服务交互模式。它强调传输的是语义完整的业务文档（比如一张订单、一份发票、一个客户资料），而不是对某个远程方法的调用指令。
核心是“传数据”而非“调方法”
文档驱动不关心服务端具体有哪些函数或操作，只约定双方交换的文档结构和含义。客户端构造一个符合契约（如XSD或JSON Schema）的文档发过去，服务端解析、处理，再返回另一个结构化文档。整个过程不暴露内部接口细节，耦合度低，更适合异构系统集成和长期演进。
- 请求体通常是完整XML实例（如
123 ... - 同一个端点（endpoint）可能处理多种文档类型，靠文档内容本身区分业务意图
- 服务契约定义在消息结构上（如WSDL的
document/literal绑定），而非操作签名上
RPC风格：像调本地函数一样调远程服务
RPC（Remote Procedure Call）风格把Web服务看作一组可远程调用的方法。请求明确指定要执行的操作名（如getCustomerById），并附带参数列表；响应则对应方法的返回值。它更贴近编程语言的函数调用思维，但容易将客户端与服务端实现细节绑定。
- 请求体常为包裹式XML（如
456 - 每个操作通常对应独立的WSDL
- 容易导致“RPC over HTTP”——HTTP仅作传输通道，未充分利用其语义（如GET/POST/PUT含义）
关键区别在抽象层级和演进能力
文档驱动围绕业务文档建模，天然支持松耦合、版本兼容和协议中立；RPC风格围绕接口方法建模，开发直观但服务变更时客户端往往需同步更新。例如，增加一个订单字段，在文档驱动下只需扩展Schema并保持旧字段向后兼容；而在RPC风格中，若原方法签名固定，可能需要新增方法或破坏性升级。
- 文档驱动更适合B2B集成、行业标准报文（如UBL、HL7）、需要长期稳定契约的场景
- RPC风格常见于内部微服务早期设计、工具自动生成客户端（如.NET Web Reference）、或REST中过度使用POST模拟动作的情况
- 现代RESTful API若遵循资源导向（用URL标识资源，用HTTP动词表达意图），其实更接近文档驱动思想——传递的是资源表示（representation），不是方法调用
基本上就这些。文档驱动不是技术噱头，而是对“系统间交换什么”这一问题的不同回答：是交换一份有明确业务意义的文档，还是发起一次远程函数调用。
