RESTful API的黄昏：一场被误读的简单性崇拜
当Roy Fielding在2000年的博士论文里写下Representational State Transfer时，他或许没有预料到，这套学术化的架构约束会在二十年后成为全行业最被滥用的话语符号。今天，几乎所有打着REST旗号的产品都只完成了其中两个约束：URI作为资源标识，以及HTTP动词作为操作语义。至于超媒体即应用状态引擎（HATEOAS）、内容协商、无状态性、缓存机制，多数团队连概念都未曾听闻。我们不妨诚实一点：绝大多数自称REST的API，不过是披着CRUD外衣的远程过程调用（RPC）——它们用名词的语法隐藏了动词的本质，用HTTP的壳掩盖了契约的混乱。这种自欺欺人的“REST化”运动，恰恰是对REST精神最深的背叛。
REST被奉为圭臬的根源在于人们对“标准”的执念。在单体应用时代，REST的姿势优雅且自洽：统一接口降低协作成本，资源模型让数据流清晰可见，无状态性使得水平扩展信手拈来。然而当微服务拆分到上百个网关、业务链路跨六七个系统时，资源导向的完美乌托邦瞬间崩塌。你不得不为了一个聚合查询发明/reports/summary这种根本说不清是资源还是动作的端点；你为了减少客户端请求次数，硬生生在/order上挂个?fields=items&expand=customer&filter[date]=...的参数串，最终变成一部需要三页文档来解释的“简易API”。这就是普遍的现实：REST的简单性只存在于hello world级别，一旦进入复杂的业务域，它那套严格的“资源”想象立刻退化为大量非标准动词、深嵌套路径、副作用不明确的PUT和PATCH，以及最致命的——为适配前端而不断膨胀的多态端点。
如果我们把REST、传统RPC和GraphQL放在同一个光谱下对比，会发现三者的本质差异在于“谁来承担理解业务的复杂度”。RPC（如gRPC）用强IDL定义方法，明明白白地承认：业务是动作，接口是函数调用。GraphQL则把选择权交给客户端，让查询总是恰好返回所需数据，代价是服务端必须处理一组复杂的解析器、批处理和防滥用策略。而REST试图走中间路线：用名词抽象静态世界，用动作暗示动态行为，却恰恰把“建模的真实意图”变成了内部矛盾。例如当状态机转移（如订单从待支付到已支付）无法用POST/PUT表达时，团队要么创造/order/{id}/pay/这种动词式端点，要么引入“动作子资源”的诡辩。这类设计既不是REST也不是RPC，而是语义垃圾桶。真正独立的观点是：我们不必在“纯REST”和“显式RPC”之间二选一，而是应当根据资源幂等性、操作确定性、领域事件强度来决定边界——但讽刺的是，越晚进入REST潮流的团队，越容易陷入教条的清规戒律里不能自拔。
那么，凭什么说不放弃REST，如何走向务实？我的建议是拥抱“面向能力的超媒体-混合REST”模式，而不是回到无脑的SRP：将核心资源继续用URI + HTTP语义暴露，但凡是涉及动作、流程或状态转移的交互，一律采用自定义媒体类型，配合Link关系与action元素来显式描述可选操作，而不是把所有逻辑塞进预定义端点。例如，订单资源仅提供静态信息与/transitions/备选动作列表，客户端按HATEOAS链路寻路，最终通过POST发起状态变迁——这样既保留了REST的可缓存性与无状态性，又复用了RPC的动作清晰度。更重要的是，API设计者必须逃离“资源=数据库表”的思维定式，转而以业务上下文来划分子域。资源是行为的投影，不是数据的贴片。当我们将checkout（结账）建模为资源时，PATCH和POST的语义争议立刻消失，因为结账本身就是可查询、可取消的实体化流程——这才是以REST之名行架构该做之事。
最终，我们需要承认：RESTful API的坏名声都源于狂热者的简化。任何只谈简单、不论代价的架构原则都是蛊惑人心的口号。REST不是没有价值——它在缓存友好型、可发现性要求高、写少读多的公共接口设计中依然是无双的；但在多模业务、命令密集型分布式系统中，它没有资格当唯一真神。本文绝不倡导废弃REST，而是倡导在技术选型中破除对名词天然的好感。判断一个API是否“好”的维度只有一个：它是否让生产端的推理变得容易，让消费端的使用变得自然。当你可以做出这个判断时，今天的架构讨论才算真正挣脱了Fielding博士论文的权力阴影。
