一、被误读的REST：从抽象原则到教条主义
Richardson成熟度模型将REST划分为四个层级，但现实中的绝大多数所谓“RESTful API”只停留在第二层——使用HTTP动词和URL资源。这种浅层实践导致行业对REST的批评越来越响亮，甚至有人断言REST已死。然而，这种判断本身就犯了以偏概全的错误。REST的核心约束是超媒体即状态转换（HATEOAS），而这一约束在Web初期并未被真正采纳，因为当时的工程实践需要的是简单可用的接口，而非完美的理论架构。
当我们重新审视REST的五大约束——客户端-服务器、无状态、缓存、统一接口、分层系统——会发现它们并非摆设。无状态保证了水平扩展的可行性，缓存提升了性能边界，统一接口将客户端与服务器解耦。遗憾的是，许多团队在落地过程中丢弃了缓存与超媒体，仅保留CRUD式URL，于是诞生了一种名为“RESTful”的伪RPC。这种伪RPC既没有REST的弹性，也没有RPC的清晰契约，最终变成两头不讨好的缝合怪。
真正的REST应该是一种“动态协议”，其响应中嵌入关联动作的链接，客户端不再依赖硬编码URL。Google的某些内部API，以及开源项目如Spring Data REST，正是对HATEOAS的典型践行。但为什么这种模式未成主流？原因在于它增加了前后端协作的认知成本，且调试工具支持不完善。当开发效率成为第一优先级时，人们宁可用自动化脚本生成OpenAPI文档，也不愿花时间设计可自描述的资源状态图。
在我看来，REST的困境并非源于理论缺陷，而是源于工程妥协与工具链的断代。我们既没有彻底抛掉它，也没有优雅地实现它，这本身就是一种尴尬的中间态。
二、横向对比：REST、GraphQL与gRPC的本质差异
要评价REST，就必须将它放在更广阔的API风格谱系中。GraphQL诞生于Facebook，旨在解决移动端弱网环境下多接口聚合的问题，其声明式数据获取让客户端按需请求字段，从而减少冗余传输。但GraphQL以激进的前置公约为代价，服务端必须定义复杂的数据图，且缓存策略变得异常困难。相比之下，REST的缓存机制天然复用HTTP缓存，而GraphQL的POST行为几乎无视浏览器缓存，迫使团队引入persisted queries或定制CDN规则。
gRPC则走向另一个极端：以protobuf定义强类型契约，通过HTTP/2多路复用提高传输效率，适合内部微服务间高吞吐、低延迟调用。但gRPC的二进制格式不易被浏览器直接解析，需要grpc-web代理，且人类可读性差——这恰恰削弱了API作为“产品”被消费的能力。REST依赖纯文本JSON，让任何一个工程师在五分钟内就能理解，而gRPC的schema编译流程则提升了入职门槛。
对比三者，可画出一条光谱：REST位于最左端，强调简单、可见、松散耦合；GraphQL位于中段，强调诉求精准、减少多次请求；gRPC位于最右端，强调性能、强类型、多语言代码生成。没有谁完全取代谁，只有谁更匹配具体语境。例如，对外开放的第三方API，REST仍是最稳妥的选择，因为其可读性和生态最成熟；面向内部高频调用的BFF层，gRPC可节省大量带宽；而面对复杂嵌套的前端页面，GraphQL能显著减少瀑布请求。
但行业普遍存在“流行度驱动技术选型”的惯性：看见某大厂切换GraphQL就盲目跟随，结果缓存、鉴权、限流全要重新设计。这种浮躁恰恰违背了API设计的本质——为调用者带来确定性，而非为开发者炫技。
三、独立观点：REST的“可预测性”是它真正的护城河
当前主流观点倾向于批判REST的“多重URL/动词组合”会产生混沌，但我认为，混沌并非源于REST本身，而是源于没有约束的“伪REST”。当一个团队明确遵循OpenAPI规范，并严格限制资源命名和状态码语义，那么REST就足以形成一种高度可预测的接口。可预测性意味着客户端可以在完全不知道服务器实现的情况下，根据已知的HTTP状态码、每项资源的标准操作，推断出下一步动作。这种“低认知成本”在大规模分布式系统中是极其宝贵的。
反过来看GraphQL，其高度灵活有时反而成为灾难。客户端可以任意嵌套查询，造成N+1问题，服务端需要编写loader和datafetcher来兜底。而gRPC的强类型虽然有助于编译期校验，但一旦版本升级，兼容性处理比REST更繁琐——你必须维护多个proto版本并处理字段编号不变量。REST则通过简单的路径版本（/v1/、/v2/）甚至内容协商就能轻松迭代，这种渐进式演进能力被严重低估。
我必须指出，在未来很长一段时间内，REST依然会是公有API市场的通用语言。AWS、Stripe、GitHub等一线服务商均以REST为主，同时补充少量GraphQL端点。这不是因为他们缺乏技术洞察力，而是因为他们懂得“多数开发者”的真实需求：快速上手、丰富文档、稳定且可缓存的GET接口。那些宣称REST已死的论调，往往来自从一开始就没有正确使用REST的团队。
因此，我的结论是：REST不应被抛弃，而应被“去伪存真”。我们不必追求百分之百的HATEOAS，但至少要让资源建模符合业务语义，合理运用缓存头，并尝试在响应中附上相关资源链接——这已足够让REST重新焕发生机。
四、未来趋势：混合架构下的API策略，不是非此即彼
随着微服务与前端技术栈的持续演进，主流企业已经开始采用“多风格并存”的API架构。例如：对外公开的合作伙伴接口继续使用REST，内部服务间调用改用gRPC，而对移动端可能再叠加一层GraphQL BFF（后端对前端）。这种混合模式并非技术冗余，而是对不同调用者给予最佳体验的合理妥协。真正的专业设计者，不是信仰一种风格，而是能在复杂需求中权衡取舍，让每种协议都在最舒适的区域发挥作用。
API网关充当了这种混搭的整合层，将REST资源映射为gRPC方法，或将GraphQL查询转换为后端REST请求。但这要求研发团队拥有足够强的抽象能力，避免落入“翻译层地狱”。我最推崇的实践是：以REST作为统一接口面，以GraphQL作为高级查询扩展，以gRPC为内部底座的“同心圆模型”。该模型既保持了基础接口的稳定性，又兼顾了数据请求的灵活性，同时使得性能关键路径得到优化。
在未来的AI工具辅助下，API文档生成、客户端SDK自动化和契约测试都将进一步演进，缩小不同协议之间的体验差距。届时REST的简单性将使其更容易被AI理解和生成。也许很快，我们就能用自然语言描述需求，AI自动翻译成REST资源定义和HTTP交互流程。到那个阶段，REST的“可读性”将成为其最强优势——相比二进制和高度递归的查询语言，自然语言与JSON之间的障碍显然更小。
综上所述，REST不会死，它只是褪去了追逐热度的浮躁外衣，回归到“网络应用架构”的本源。面对未来，我们需要的不是另一种全新技术所引发的革命，而是对现有原则的深刻洞察和创造性应用。这，才是API设计真正的黄金分割点。