企业官网建设流程全解析

• 后端
• 文档
• 教程

本指南以 system-design-101 仓库中 API 架构风格对比速查 为核心骨架，系统梳理当前最主流的六种 API 架构风格——SOAP、REST、GraphQL、gRPC、WebSocket 与 Webhook。读完本文，你将掌握每种风格的数据格式、底层协议、通信模型与典型适用场景，能够在系统设计面试和真实架构选型中快速判断"这个场景该用哪种 API 风格"，并知道如何在本仓库中进一步查阅每种风格的原理级资料。

一、六种主流风格概览

原速查文档明确给出：本文覆盖当前最流行的六种 API 架构风格：

• SOAP——基于 XML 的严格契约式消息协议
• REST——基于 HTTP 的资源化架构风格
• GraphQL——客户端自定义查询的图式 API 语言
• gRPC——基于 HTTP/2 与二进制编码的高性能 RPC 框架
• WebSocket——全双工长连接的实时通信协议
• Webhook——事件驱动的服务间 HTTP 回调

正如仓库中 SOAP vs REST vs GraphQL vs RPC 一文所述："随着时间推移，不同的 API 架构风格相继出现，每种风格都有自己的数据交换标准化模式。"理解它们各自的标准化方式，是正确选型的前提。

二、SOAP：严格契约的 XML 消息协议

SOAP（Simple Object Access Protocol）是最早被大规模采用的 API 风格之一，属于六种风格中契约化程度最高的方案。

核心特征：

• 消息体使用 XML 编码，通过 SOAP Envelope 封装请求与响应；
• 依赖 WSDL 等契约文档预先定义接口结构与数据类型，调用方与服务端必须严格对齐；
• 传输层通常走 HTTP/HTTPS，也可承载于 SMTP 等其他协议之上；
• 具备 WS-Security 等一整套企业级安全与事务扩展规范。

典型场景：金融、电信、政企等对契约、审计与安全合规要求极高的系统间集成。其代价是 XML 冗长、解析开销大、契约变更成本高，因此在内部微服务通信与移动端场景中逐渐让位于更轻量的风格。

三、REST：以资源为中心的 HTTP 架构风格

REST（Representational State Transfer）是当今 Web 领域应用最广泛的 API 风格。仓库中的 REST API 速查 将其核心内容归纳为：六大 REST 设计基本原则，HTTP 方法、协议、版本化等关键组件，以及分页、过滤与端点设计等实战细节。

核心特征：

• 以"资源"为中心，通过 URL 表达资源、HTTP 方法表达操作（GET / POST / PUT / DELETE 等）；
• 无状态通信，每个请求携带完整上下文，便于水平扩展；
• 数据格式以 JSON 为主（也支持 XML），对客户端友好、调试成本低；
• 借助 HTTP 状态码表达语义，配合分页（page/limit）、过滤（filter）等约定解决大数据量查询。

典型场景：面向公网的 CRUD 类 Web API、前后端分离应用、第三方开放平台。REST 的表达能力在复杂的多资源关联查询与实时场景下会显得力不从心，这也是 GraphQL、gRPC 等风格出现的原因。

四、GraphQL：客户端主导的查询语言

GraphQL 由 Facebook 开源，解决的核心痛点是 REST 的"过度获取"与"请求爆炸"：客户端可以在一段查询中精确声明需要的字段与关联数据。

核心特征：

• 单一端点，客户端通过 Schema 定义的查询（Query）、变更（Mutation）与订阅（Subscription）获取数据；
• 客户端按需取字段，减少冗余传输，一个请求可聚合多个资源；
• 服务端提供强类型 Schema，天然具备可发现性与自文档化能力。

仓库内的真实案例：LinkedIn 的 GraphQL 实践 展示了一个完整的企业级落地流程，分三步：

1. 编辑与测试查询：客户端开发者编写查询并与后端服务联调；
2. 注册查询：提交查询到查询注册表（query registry），并将路由元数据一并登记；
3. 生产使用：查询随客户端代码一起发布，路由元数据用于流量路由层将请求导向正确的服务集群，运行期缓存已注册的查询；一条示例查询会先访问 identity 服务获取成员信息，再访问 organization 服务获取公司信息。

值得注意的工程取舍是：LinkedIn并未部署 GraphQL 网关，原因有二——避免引入额外的一跳网络开销，以及避免单点故障（SPOF）。

典型场景：BFF（Backend for Frontend）层、数据面广且字段组合多变的移动端应用、需要聚合多个下游服务的场景。代价是服务端缓存与限流复杂度上升、查询可控性需要额外治理（如查询注册表与复杂度分析）。

五、gRPC：HTTP/2 之上的高性能 RPC

gRPC 是面向微服务内部通信的高性能远程过程调用（RPC）框架。仓库中 gRPC 工作原理 给出了完整的数据流说明：RPC 之所以被称为"远程"调用，是因为它让部署在不同服务器上的服务能够相互通信，而从调用方视角看，它就像一次本地函数调用。

核心特征：

• 使用 Protocol Buffers（proto）定义 IDL，自动生成客户端 stub 与服务端骨架代码；
• 基于 HTTP/2 传输，支持头部压缩、多路复用与双向流式通信；
• 消息体经过二进制编码，相比 JSON 显著减小体积并降低序列化开销。

调用链路（以订单服务调用支付服务为例）：

1. 客户端发起一次 REST 调用（请求体通常为 JSON）；
2. 订单服务作为 gRPC 客户端接收该请求，将其转换后向支付服务发起 RPC 调用，gRPC 把客户端 stub 编码为二进制格式并交给底层传输层；
3. gRPC 通过 HTTP/2 在网络上发送数据包——由于二进制编码与网络优化，原文档指出 gRPC 的传输速度可达 JSON 方案的数倍量级；
4. 支付服务（gRPC 服务端）从网络接收数据包、解码后调用服务端应用逻辑；
5. 结果从服务端应用返回，再次编码并送入传输层；
6. 订单服务接收数据包、解码，把结果返回给客户端应用。

典型场景：微服务间高吞吐内部调用、低延迟的流式数据交换（如实时订阅、音视频控制面）、多语言异构服务互通。相对短板是浏览器端支持受限、调试不如 REST 直观，一般不建议直接暴露给公网客户端。

六、WebSocket：全双工实时通信

WebSocket 解决的是"HTTP 服务器无法主动向浏览器发起连接"这一根本限制。仓库中的 轮询、SSE 与 WebSocket 对比 把实时方案分为两类：

• 浏览器承担主要工作：短轮询（浏览器反复重试直到拿到最新数据）与长轮询（HTTP 服务器在数据到达前不返回响应）；
• 浏览器与服务器协同：WebSocket 或 SSE（Server-Sent Events）。连接建立后服务器都能直接推送最新数据，区别在于SSE 是单向的（浏览器不能再向服务器发新请求），而WebSocket 是全双工的（浏览器可以持续发送新请求）。

核心特征：

• 通过 HTTP Upgrade 握手升级为持久 TCP 连接；
• 全双工双向通信，服务端可主动推送，浏览器可实时上行；
• 消息为帧化二进制/文本，通信延迟远低于轮询。

典型场景：在线聊天（如 Slack 消息的旅程 一类的实时消息系统）、实时协作编辑、行情推送、在线游戏与直播互动。代价是需要维护长连接状态，对连接管理与横向扩展（如连接网关、心跳保活）要求较高。

七、Webhook：事件驱动的服务端回调

Webhook 与前五种"请求-响应"风格不同，它是一种事件通知模式：当源系统发生特定事件时，主动向预先注册的 URL 发起 HTTP 回调，把事件数据推送给订阅方。仓库中 轮询 vs Webhook 与 API 协议演进（2023） 均将其列为最流行的 API 形态之一。

核心特征：

• 方向反转：由服务端（生产者）发起，订阅方只需提供回调端点；
• 基于普通 HTTP POST，实现成本低、与现有基础设施天然兼容；
• 天然适合异步事件流，无需订阅方主动轮询。

典型场景：支付回调（支付结果通知）、Git 仓库的 Push/PR 事件、CI/CD 构建状态通知、消息队列消费后触发的下游动作等。工程上必须处理的三件事：回调重试与幂等（防止重复投递）、签名验签（防止伪造回调）、回调端点的可用性保障。

八、六种风格横向对比速查

九、选型决策要点

面对一个具体的系统设计问题时，可以沿着以下顺序快速收敛：

1. 通信方向：如果服务端需要随时主动推送、且客户端也要实时上行（聊天、协作编辑），优先WebSocket；只需服务端单向推送，SSE 是更轻的替代。
2. 事件通知：如果需求是"某个事件发生后通知下游系统"，而不是"调用接口拿数据"，选Webhook。
3. 调用方与性能：微服务内部的低延迟、高吞吐调用，优先gRPC；面向公网浏览器端的业务 API，优先REST或GraphQL。
4. 数据面复杂度：客户端字段组合多变、需要聚合多个服务，考虑GraphQL；标准 CRUD 与资源化管理，REST 足够。
5. 合规与契约：金融、政企等要求强契约、强审计的场景，SOAP仍是成熟选项。

十、在本仓库中继续深入

六种风格在 system-design-101 仓库中均有对应的高质量指南，建议按需精读：

• REST API 速查：REST 六大原则、HTTP 方法、版本化、分页过滤
• REST API 工作原理 与 REST API vs GraphQL：REST 与 GraphQL 的取舍细节
• gRPC 工作原理 与 什么是 gRPC：gRPC 完整数据流与原理
• LinkedIn 的 GraphQL 实践 与 GraphQL 落地模式：企业级落地流程
• 轮询 / SSE / WebSocket 对比：实时通信三方案原理
• 轮询 vs Webhook：事件通知模式细节
• 2023 API 协议演进全景：六种协议与各自的收益、挑战综述
• API 设计速查：跨风格的通用 API 设计规范

把本文的对比维度与上述指南的原理细节结合起来，你就能在系统设计面试中面对任意"实时推送 / 服务间通信 / 开放平台 API"类问题时，给出有理有据的风格选型结论。

• 后端
• 文档
• 教程