引言
RESTful API曾一度被认为是现代API设计的黄金标准。自Fielding的博士论文提出以来，其以资源为中心、统一接口、无状态等约束，为分布式系统提供了优雅的蓝图。然而，随着微服务、移动互联网和云原生时代的到来，REST的局限性在复杂业务场景中愈发明晰。越来越多优秀的替代者——GraphQL、gRPC、Cap'n Proto——开始挑战它的统治地位。我们是否正在目睹REST的黄昏？还是说，它只是被误解得深重？本文将针对这一命题展开深度剖析。
对比：REST与GraphQL的取舍
当谈到REST的主要痛点，必然绕不开数据载荷的过载和请求次数的爆炸。比如一个需要展示文章及作者信息的页面，REST往往要求客户端先后请求/articles/{id}和/users/{id}，或者服务器设计复杂的复合端点来缓解，但每种复合端点都是对REST统一接口的破坏。GraphQL允许客户端精确指定所需字段，一次性获得嵌套数据，并天然规避后续数据团新增字段时造成的前端回归问题。然而，GraphQL也带来了无法回避的代价：服务端需要处理更复杂的查询解析、权限校验和安全性控制，缓存策略也远比HTTP缓存复杂。更关键的是，GraphQL强依赖Schema的演进，这增加了前后端的协作成本。而REST的简单性、可读性和对HTTP基础设施的充分利用，仍然是大多数中小型团队的最佳起点。
对比：REST与gRPC的竞争力
将视线转向微服务内部互联。gRPC基于HTTP/2，采用Protocol Buffers作为接口定义语言（IDL），支持双向流式通信以及强类型限制。与REST相比，gRPC在多服务场景下具有更低的延迟和更紧凑的数据编码，极大的网络、CPU开销减少。REST使用文本JSON，虽然易读但在高并发和大量数据传输时相形见绌。此外，gRPC的契约驱动开发能极大促进团队间的协作，自动生成的客户端和服务端代码避免了手工API文档的同步问题。但gRPC也并非总是正确的选择。它要求较强的工程能力，且在浏览器端传播受限，复杂了跨语言的可调试性。REST依然在跨组织的公开API、物联网和浏览器应用中占据主导。所以，真正的问题不是“REST还是gRPC”，而是“这里是否真的需要性能与强契约”。
独立观点：REST是一种哲学，不是协议
本文认为，围绕REST的争议本质上源于它的“双重标准”。Fielding给出的REST约束——资源标识、表述、自描述消息、超媒体——更像是一种设计哲学，而不是一个技术规范。然而，绝大多数实际系统自称RESTful，却根本没有实现超媒体。换句话说，我们正在用“REST的假名”为普通HTTP API买单。这导致出现两个极端：一边是盲目遵循“资源路径无动词”等教条，另一边则是视REST为无用的老古董。其实，REST的核心价值在于资源的语义化和同构性，而不在于URL长得是否好看。例如，POST /orders/123/cancel是否不是REST？如果cancel是一个真正的业务动作，而不是对某个资源状态的变化，那它本身就是一个过程。真正的REST思想并未反对过程，而是反对将过程伪装为资源。因此，当我们批评REST时，批评的常常是商业中“RESTful”标签下的实用主义膨胀。
实践中的反模式与务实变革
如今，开发者们热衷创造“伪RESTful”的反模式。比如，将所有操作纳入HTTP方法（包括GET带请求体），或者滥用200状态码掩盖业务异常，又或者将完全无关的业务节点强行建模为父子资源关系。这些反模式的根源并非REST本身，而是缺少对业务边界的理解。为应对这一困境，业界开始涌现一种务实混合风格：保留REST的资源表达和HTTP标准化，同时引入非REST的处理机制去覆盖复杂交互。例如，在服务节点内部使用gRPC，而对外部暴露REST；或者从实践上允许端点设计面向动作（比如/checkout）而不是拘泥于名词动名词。真正有智慧的架构，不是遵守某一种典范，而是理解每一种工具背后的动机，并围绕业务领域和团队能力做最适当的取舍。REST不会消失，它依然值得被珍视，只是我们要放弃神话它的幻觉。