1.3 为什么选择 RESTful：契约的性价比

1.3 为什么选择 RESTful：契约的性价比

本节摘要：RESTful 成为 Web API 主流，靠的是可伸缩性、可演进性与低耦合三笔长期回报。但它不是万能解——严格 REST 要付出超媒体与内容协商的实现成本，追求实时推送、类型强约束或复杂图查询的场景，RPC、gRPC、GraphQL 反而更划算。本节给出选型时先看哪三个问题，再亮出对照取舍。

学习目标

阅读完本节，你应当能够：

1. 从可伸缩性、可演进性、低耦合三条主线列出 REST 的核心回报。
2. 说清 REST 在单次调用效率上的相对劣势来源。
3. 对照 RPC、gRPC、GraphQL 指出它们各自更适合什么场景。
4. 提出选型时依次要问的三个问题，并把 REST 放回它该在的位置。

把可伸缩、可演进、低耦合这三笔账摊开

每种风格都靠三条确定性回报攒人气。REST 的三条，和它的约束体系一一对应：

• 可伸缩性：无状态让任意服务器处理任意请求，水平扩展没有粘性会话阻拦；可缓存让读多写少的压力被就地吸收。这两条直接来自第 1.2 节的约束，不是附加福利。
• 可演进性：统一接口让客户端依赖"资源的抽象"而非"某个实现"，服务器加资源、改结构，只要不破坏契约，客户端不用跟着跳。
• 低耦合：客户端与服务器可以独立开发、独立部署，接口是它们之间唯一能咬合的地方。

顺手可提的是"生态红利"：因为普及，几乎每种语言都有现成的 REST 客户端与服务端框架，人才好找，工具链全，踩过的坑多。这条看着软，工程落地时往往最快变成现实收益。它的底层逻辑不难懂——REST 是默认选项，所以脚手架、文档生成、监控告警、契约校验这些周边工具都默认先支持它，招来的工程师几乎不用额外培训就能上手维护。反过来想，一个刚成立的小团队真去上 gRPC 或 GraphQL，光是让全员统一熟悉 IDL、调通网关、配好查询解析，就要先交一大笔"学习税"。这笔税不是不能付，而是要在确定高频红利能覆盖它时才值得付。

二、账的另一面：REST 放弃了什么

任何契约都有它的隐形成本，REST 不例外。

• 单次调用效率：基于文本的表示（JSON 体积相比二进制协议更重）、每个请求自备信息，换来的是通用性，代价是每次调用要携带更多字节、做更多解析。
• 实现成本：真要做全 HATEOAS、内容协商、超媒体导航，工程复杂度明显高于"套 RPC"。多数团队做到"能用 HTTP 方法 + JSON"就收手，正说明满配 REST 的实际成本。
• 不适合"高频小动作"：持续推送、毫秒级回调、强类型契约这类需求，原生的流式与类型验证并不在手边。

把这三笔成本再看得细一点，要点是"不是每笔订单都付全款"。单次调用效率的损耗，对"一个页面一次拉回整张图书列表"这种读多写少的用法几乎无感，缓存一上还倒赚；但对"每毫秒都在互调的撮合轮询"，文本解析的每一点开销都会被放大。所以判 REST 值不值，不能只看风格本身，要看它的损耗在你这套业务里占不占主导。可伸缩性在 CRUD 读多场景红利最大，实时推送场景红利最弱；可演进性在"要长期维护、接口会变"的场景才值钱，一次性脚本调用就无所谓。投入和回报对不上号，这才是 REST 看起来"不够快"的真正原因。

⚠️ 常见坑：为一个"内部几台服务之间高频互调"的场景硬上严格 REST，谈资源设计谈半天，最后发现吞吐差了、延迟高了。这时该承认：这是 RPC 的地盘。

三、对照：RPC、gRPC 与 GraphQL 都在哪占位

把主要竞争对手拉上同一张表，取舍就清晰了：

具体展开三条：

1. RPC 与 gRPC：把网络调用包装成"调用一个函数"，接口即方法签名，类型由 IDL 强约束。内部服务间这种调用密集、类型稳的场合，gRPC 用二进制协议在吞吐和延迟上明显占优。代价是契约与实现绑得紧，演进要同步升版本两端。
2. GraphQL：客户端指定"我要这些字段、这些关联"，一次请求拿齐，解决 REST 里"拼命造字段组合端点或要打多次请求"的痛点。代价是把解析压力集中到服务端，且查询级缓存远比 URL 级缓存难做。
3. REST：站在中间，用"资源 + 统一方法 + 状态码"换取最大普适性。适合对外服务、跨团队交付、需要长期演进和生态兜底的公共接口。

💡 关键直觉：三者不是敌是邻。很多体系是"内部 gRPC 高速路 + 对外 REST 敞门厅"的组合，一句话：REST 管门面，gRPC 管里子。

四、选型先问这三个问题

与其背结论，不如把判断权握在自己手里，选型时依次问三句：

1. 谁是这个接口的使用者？ 对外部开发者开放、要长期维护 → REST 的普适性与演进性派上用场；就内部两三个服务 → 可以直奔 RPC 的高效。
2. 调用密度高不高、实时性要不要？ 高频小动作、需要推送回调 → 考虑 gRPC 流或事件；读多写少、天然适合缓存 → REST 的可缓存红利吃满。
3. 字段需求变不变、查询复不复杂？ 客户端经常需要不同字段组合 → GraphQL 更顺手；字段稳定、就是逐资源增删改查 → REST 够且更简单。

按这三问过一遍，大部分接口都能快速落位，REST 会把其中"对外、低频变化、可缓存、需演进"的一类接走——这正是它最该有的角色。

拿一家把图书零售搬到线上的书店举例，把三问走一遍。使用者是两类：面向外部购物 App 的公开接口，和内部订单撮合服务之间的几处高频调用。第一问就对上了：公开那批必然要 REST，因为要接的客户端千变万化、还得长期维护；内部那几处撮合调用，方法签名稳定、每秒几十次的轮询，就专给 gRPC。第二问：公开的图书详情是典型的读多写少，天然能吃满缓存红利；内部撮合是低延迟敏感，gRPC 二进制更省。第三问：购物 App 常要"书的详情+库存+作者其他作品"这种字段组合，早期曾想用 GraphQL 一把抓，后来评估查询权重不高，决定先用 REST 的嵌套资源，真顶不住再升级。最终落位：门面 REST，里子 gRPC，各守各的确定性回报。这条拆分路径，任何团队都能照着复用。

本节要点回顾

• 要点一：REST 靠可伸缩性、可演进性、低耦合三笔回报成为主流。
• 要点二：它的相对弱势在单次调用效率与实时性，满配实现成本偏高。
• 要点三：内部高频互调优先 gRPC，字段多变优先 GraphQL，对外长期契约优先 REST。
• 要点四：三者常共存：内部 RPC 做里子，对外 REST 做门面。
• 要点五：选型三问是"谁来用、多密多实时、字段变不变"。
• 要点六：结论服务于取舍，不做一个风格的忠诚推销员，这是契约思维的第一步。

选好了方向，"载体"就该登场了。下一节我们把 HTTP 协议这套语法彻底过一遍，它是后续所有契约条款的落笔媒介。