请求解析API、Web API、REST API、Web Services、SOAP Services的概念与关联
2026-5-7
我太懂这种面试时被术语绕晕的感觉了！这些概念确实边界重叠又各有侧重，很多资料要么讲得太散要么太学术，我结合自己踩过的坑和整理的内容，给你把它们掰得明明白白：
1. API：最底层的核心概念
API全称是Application Programming Interface，说白了就是「不同软件之间沟通的规则」。它的范围超级广，不止局限于网络：
- 你用Python调用
os.mkdir()创建文件夹，这是本地的系统API； - 前端JS调用
document.getElementById()操作DOM，这是浏览器API； - 你调用微信支付的接口，这是网络API。
核心是：只要是两个程序之间约定好的交互方式，都能叫API。
2. Web API：API的Web专属子集
Web API是API的一个分支，特指通过网络（主要是HTTP/HTTPS协议）实现的API。简单说就是“跑在Web上的API”，比如：
- 调用高德地图的地理编码接口；
- 后端给前端提供的接口，比如
GET /api/users获取用户列表。
它是API在Web场景下的具体实现，所有需要跨网络通信的程序间交互，基本都属于Web API的范畴。
3. Web Services：早期的“Web服务”概念
Web Services是一个偏传统的术语，本质上也是Web API，但它特指那些遵循早期跨平台互操作标准的服务。在REST流行之前，企业级系统之间的集成基本靠它，核心特点是：
- 用WSDL文件定义接口的结构和规则；
- 用UDDI来注册和发现服务；
- 通常基于SOAP协议实现（这也是它和SOAP绑定很深的原因）。
现在这个术语已经慢慢被“Web API”取代，但老系统里还能见到。
4. SOAP Services：Web Services的典型实现
SOAP是Simple Object Access Protocol的缩写，是一种严格的、基于XML的通信协议，是Web Services最常见的实现方式。它的特点是“重规范”：
- 消息必须遵循固定的XML格式（Envelope包裹Header和Body）；
- 内置了安全、事务、错误处理等复杂机制；
- 适合对可靠性要求极高的企业级场景，但缺点是繁琐、性能不如轻量接口。
比如早期的银行系统、ERP系统的集成接口，很多都是SOAP Services。
5. REST API：Web API的现代流行风格
REST是Representational State Transfer，它不是一个协议，而是一种架构设计风格，用来指导如何设计简洁高效的Web API。核心原则包括：
- 用URL表示资源（比如
/users/123代表ID为123的用户）； - 用HTTP原生方法（GET/POST/PUT/DELETE）对应对资源的操作；
- 用HTTP状态码反馈结果（200成功、404找不到、500服务器错误）；
- 数据格式常用JSON（轻便易读）。
现在绝大多数互联网公司的开放接口、前后端交互接口都是REST风格的，也是面试里最常问的类型。
它们的相互关系梳理
用一个包含关系来总结就清晰了：
- API是最大的集合，包含所有类型的程序接口（本地、网络、硬件等）；
- Web API是API的子集，仅指基于网络的接口；
- Web Services是Web API的一个传统分支，对应SOAP这类早期标准实现；
- SOAP Services是Web Services的具体实现，属于Web API的一种；
- REST API是Web API的现代设计风格，不属于传统Web Services的范畴（虽然有人会宽泛归类，但严格来说是两种不同思路）。
面试时被问这类问题，先从大的范围切入，再逐个拆解每个术语的核心特点，就能避免混淆啦！
内容的提问来源于stack exchange，提问作者DSR
