一、为什么又一次提起‘老掉牙’的对比
云原生、微服务、Serverless 等新概念层出不穷，技术雷达年年翻新，可“到底用 WebAPI 还是 WebService”依旧频繁出现在架构评审、外包招采、旧系统改造场景里。原因并不神秘：
云原生、微服务、Serverless 等新概念层出不穷，技术雷达年年翻新，可“到底用 WebAPI 还是 WebService”依旧频繁出现在架构评审、外包招采、旧系统改造场景里。原因并不神秘：
-
企业内部的‘上古’ERP、支付通道、短信网关仍在用 WSDL 暴露服务，维护团队必须理解其底层协议；
-
监管部门对报文格式、签名算法、传输可追溯性有硬性要求，贸然更换协议反而增加合规风险；
-
同一组织内‘新一代’系统与‘遗留’系统需要共存，技术决策者必须权衡迁移成本、性能差异、人员技能与未来扩展空间。
本文跳出“谁快谁慢”的简单对比，从历史背景、协议栈、消息格式、安全模型、工具链、测试策略、性能、演进路径八个维度拆解两条技术栈的差异，帮助开发者在“选新”与“守旧”之间做出更理性的判断。
二、历史脉络：从‘远程方法’到‘资源表述’
WebService（下文简称 WS）诞生于 2000 年前后，面向“企业级异构系统互联”：
WebService（下文简称 WS）诞生于 2000 年前后，面向“企业级异构系统互联”：
-
网络环境低速、不可靠，需要一次握手完成多步业务；
-
开发语言多样，C++、Java、VB、Delphi 并存，大家渴望‘语言无关的 RPC’；
-
业务场景以交易、转账、库存冻结为主，强调强一致性与可审计性。
WebAPI（下文简称 API）则伴随 Web 2.0 与移动互联网崛起： -
带宽与终端数量爆炸，HTTP 被证实足以承载高并发；
-
前后端分离成为默认模式，浏览器、App、IoT 设备都需要‘轻量级’接口；
-
持续交付理念流行，接口需要频繁迭代，人类可读的文档比机器生成的元数据更受青睐。
理解两条技术栈的诞生背景，就能明白为何 WS 重“契约”、API 重“简洁”；二者并非简单的新旧替代，而是面向不同痛点给出的历史答案。
三、协议栈：一次握手 versus 无状态往返
WS 通常基于 SOAP 协议，再走 HTTP 或 SMTP 传输；消息体内包含“信封-头-体”三层结构，头里可携带事务、路由、安全令牌，一次请求即可完成“鉴权→业务→确认”全链路。
API 多数基于纯 HTTP，遵循 REST 风格，也可使用 GraphQL 或 gRPC-over-HTTP/2。默认无状态，每次请求只携带完成当前操作所需的最小信息，服务端不保存客户端上下文。
差异后果：
WS 通常基于 SOAP 协议，再走 HTTP 或 SMTP 传输；消息体内包含“信封-头-体”三层结构，头里可携带事务、路由、安全令牌，一次请求即可完成“鉴权→业务→确认”全链路。
API 多数基于纯 HTTP，遵循 REST 风格，也可使用 GraphQL 或 gRPC-over-HTTP/2。默认无状态，每次请求只携带完成当前操作所需的最小信息，服务端不保存客户端上下文。
差异后果：
-
在高延迟网络里，WS 的“一次握手”模型能减少往返次数；
-
在需要负载均衡与横向扩展的场景，API 的无状态特性让接入层可以随意增减节点，无需担心会话粘滞；
-
企业内网往往同时存在“低延迟+高一致”与“高吞吐+可扩展”两类需求，于是两条技术栈长期并存。
四、消息格式：信封与便签纸
SOAP 消息用 XML 封装，信封里可嵌套多段正文、附件、签名；同一消息可同时支持加密与压缩，且能走“多跳”路由，每一跳都能读取或改写头信息。
REST/JSON 消息则像“便签纸”，字段含义通过文档约定，结构灵活，冗余度低；解析库几乎遍布所有语言，学习成本趋近于零。
带来的权衡：
SOAP 消息用 XML 封装，信封里可嵌套多段正文、附件、签名；同一消息可同时支持加密与压缩，且能走“多跳”路由，每一跳都能读取或改写头信息。
REST/JSON 消息则像“便签纸”，字段含义通过文档约定，结构灵活，冗余度低；解析库几乎遍布所有语言，学习成本趋近于零。
带来的权衡：
-
信封模式让 WS 在“签名、加密、时间戳、原子事务”等企业要素上开箱即用，但消息体积膨胀 3～5 倍；
-
便签纸模式让 API 的报文大小与解析速度占优，却需要开发者自行实现签名、幂等、重试、链路追踪等跨切面能力。
一句话：信封适合“一次写完、十年不变”的稳态业务；便签纸适合“每周发布、字段常变”的敏态业务。
五、安全模型：内置铠甲 versus 自建城墙
WS 世界有 WS-Security 规范，提供
WS 世界有 WS-Security 规范，提供
-
消息级签名与加密（可只加密信用卡字段，其余明文）
-
安全令牌传播（支持用户名/密码、X.509、Kerberos、SAML）
-
时间戳与重放检测
这些能力以“策略断言”方式写在 WSDL，工具链可自动生成拦截器，开发者几乎零编码就能获得企业级安全。
API 则把安全职责“下放”到传输层与应用层： -
传输层：TLS 1.3 提供信道加密，但到达网关后即解密，后端微服务之间若要走零信任，需要再次加密或 mTLS
-
应用层：JWT、OAuth2、MAC Signature 等方案需要开发者理解令牌生命周期、刷新、撤销、作用域
结果是： -
WS 项目启动慢，一旦配置完成，安全合规审计相对轻松
-
API 项目启动快，却要在“网关→服务→数据库”全链路反复做安全决策，治理成本向后延伸
对金融、政务、医疗等强监管行业，WS 的内置铠甲依旧有不可替代的优势；对互联网 toC 业务，自建城墙虽然费工，却可以获得更细的权限粒度与更快的迭代节奏。
六、工具链与生态：生成式 versus 手写式
WSDL 是 WS 的“契约灵魂”，只要写好接口描述，主流 IDE 都能生成
WSDL 是 WS 的“契约灵魂”，只要写好接口描述，主流 IDE 都能生成
-
服务端桩（Skeleton）
-
客户端代理（Proxy）
-
策略配置文件
开发者只需在桩里填业务逻辑，客户端即可通过代理像调本地方法一样访问服务。
API 则缺乏“大一统”描述格式： -
OpenAPI/Swagger 需要额外写 YAML/JSON，再生成文档或代码
-
RAML、API Blueprint、GraphQL Schema 各有拥趸
-
代码优先（Code First）模式下，先写 Java/Kotlin/TypeScript，再通过注解反向生成文档
带来的现象： -
WS 团队里，新人第一天就能“Run”起来，但改动契约要重新生成桩，合并冲突令人头大
-
API 团队里，接口变更只需改代码+注解，五分钟后可上线，但契约常被“无意中破坏”，导致消费者抱怨“你偷偷删了字段”
规范策略： -
WS 侧把 WSDL 纳入版本管理，变更前先发草案，消费者确认后再合入主干
-
API 侧把契约扫描纳入 CI，当发现“删字段、改类型、改路径”就阻断合并，并自动@相关调用方
七、测试策略：单元、契约、端到端的三层天平
WS 的 WSDL 让“消费者驱动契约测试”落地相对简单：
WS 的 WSDL 让“消费者驱动契约测试”落地相对简单：
-
消费者写期望→提供者跑验证→全部通过才合入
-
工具可直接对比 WSDL 差异，生成兼容性报告
API 的契约测试需要额外约定： -
路径、方法、状态码、请求头、响应体都要写断言
-
一旦采用“代码优先”，契约变动可能滞后于实现，需要反向扫描
端到端测试层面，两条技术栈都要面对“环境不一致、数据污染、外部依赖”老三样；差异在于： -
WS 可通过“SOAP-over-JMS”或“SOAP-over-TCP”在内存总线里跑测试，绕过网络
-
API 多数走 HTTP，需要 MockServer 或 TestContainer，启动速度稍慢，但更接近真实部署
一句话：WS 测试前期配置重、后期自动化轻；API 测试前期配置轻、后期维护重。选择时要盘点团队“愿意把精力花在哪一段”。
八、性能对比：解析成本、包大小、往返次数
解析成本：
解析成本：
-
XML 解析需要遍历节点、处理命名空间，CPU 消耗约为 JSON 的 2～3 倍
-
但现代 CPU 对 XML 解析已做指令优化，在千兆网络、万兆网络场景下，差距常被“网络延迟”掩盖
包大小： -
SOAP 信封+头+WS-Security 令牌，体积膨胀 3～5 倍
-
JSON 可采用 gzip/br 压缩，压缩后体积接近二进制
往返次数： -
WS 可在一次请求里携带“多操作”，减少 RTT
-
API 若遵循 REST，往往需要多次请求才能拼装完整业务数据，可通过“字段展开”“GraphQL 聚合”缓解
综合结论： -
低带宽、高CPU场景，JSON 胜出
-
高延迟、需要“多操作原子”场景，SOAP 胜出
-
多数企业内网属于“高带宽+低延迟”，两者性能差异可忽略；真正的瓶颈在数据库、业务逻辑、序列化方式，而非“选 WS 还是 API”本身
九、演进与共存：让老系统与新系统握手
-
协议网关
在 DMZ 区部署“协议转换网关”，外部新系统走 REST，内部老系统继续 WS；网关负责“JSON ↔ XML”“JWT ↔ WS-Security”的互转，让迁移分批进行。 -
侧车代理
对无法改动的老系统，部署“侧车”代理，把 WSDL 封装成 OpenAPI，供云原生服务调用；侧车崩溃时不影响主进程，满足“可灰度、可回滚”要求。 -
双协议发布
对新建系统，可同时暴露 WS 与 REST 两种入口：
-
内部老旧 ERP 继续用 WS
-
移动端、小程序用 REST
底层业务逻辑共用，减少重复开发；通过“流量标记”区分来源，逐步观察两种协议的资源消耗，再决定何时下线 WS。
-
人员培养
不要让团队形成“REST 派”与“SOAP 派”的对立；
定期组织“WS → REST”迁移工作坊，也让只写过 JSON 的新人体验 WSDL 生成、策略配置、签名验证，理解“信封”思想；
当老系统真正退役时，团队才能平滑过渡，而非“把遗留代码扔进黑洞”。
