REST 是什么？为什么它让系统"活得更久"
Published on 2026-05-11
REST不是一种技术，是一种架构哲学。本文深入解析REST五大设计原则，揭示无状态为何是系统可伸缩性的关键，及其与SOAP的本质区别。
REST 是什么？为什么它让系统"活得更久"
2018年，某银行上线了一套基于SOAP协议的核心系统。2021年，他们决定做移动端改造。开发团队面临的第一道坎不是业务逻辑，而是——没人能在合理时间内读懂那套WSDL接口定义。最后花了八个月，先把SOAP翻译成REST，才开始真正做业务。
这不是段子。这是REST最朴素的价值：让系统活下去，而且活得体面。
REST不是一种技术，是一种"活法"
很多人知道REST是因为它和RESTful API一起出现，被当作某种"JSON化"的HTTP接口。但这个理解有点偏。
REST全称是Representational State Transfer，翻译过来是"表述性状态转移"。听起来很拗口，但它的核心想法一句话就能说清：网络上的所有东西都是资源，每个资源都有唯一地址，所有操作都通过统一接口完成，且服务器不保存任何客户端状态。
前三条还好理解。最后一条——"无状态"——才是真正反直觉的地方。
传统思维是：用户登录了，服务器记住他；加入购物车了，服务器也记住。但REST说，不行，每次请求都得自带身份证明，服务器翻脸不认人。
这听起来很蠢。但恰恰是这个"蠢"的设计，让系统拥有了横向扩展的超能力。
无状态为什么是性能外挂
服务器不记人，意味着什么？
意味着任何一台服务器都能处理任何请求。用户A的请求今天经过北京机房，明天漂到上海机房，后天换到成都机房——对他来说毫无区别。服务器集群可以随时增减，不用担心"会话粘滞"带来的负载不均。
做过分布式系统的工程师都清楚，有状态的服务做扩容有多痛苦。一个用户 session 落在哪台机器上，这台机器挂了怎么办？解决方案通常是" session 复制"或者" session 集中存储到 Redis"，但每多一步，就多一层复杂度，多一个故障点。
REST把这层复杂度直接砍没了。
举两个对比：某电商大促时扩容了200台服务器，由于采用无状态的REST API，新增机器在30秒内就自动开始承接流量。而另一家采用有状态架构的竞品，同样的扩容操作花了40分钟做状态迁移，峰值期间还出现了短暂的购物车丢失问题。
差距就这么出来的。
五条原则，每条都是代价换来的
REST的五条原则不是拍脑袋想出来的，是Roy Fielding在2000年研究了一堆Web架构之后总结出来的。每一条背后都有实际教训：
1. 一切皆资源。 用户是资源，订单是资源，甚至"当前用户的未支付订单数"也可以是资源。好处是命名统一，坏处是——有时候你觉得这是个"动作"，硬要把它拗成"资源"，会有点别扭。比如"转账"，你得把它理解成创建一个"交易记录"资源。
2. 唯一资源标识。 每个资源有且只有一个URI。这条简单，但很多团队做不好：同一个用户信息，GET /getUser、GET /queryUser、GET /user/detail都能拿到，结果是维护三套接口文档，不知道哪套是最新的。
3. 统一接口。 所有操作归结为GET/POST/PUT/DELETE。听起来限制了自由度，但换来的是全局可预测性。任何懂HTTP的人，不用看你文档，大概能猜到你的接口怎么用。
4. 操作不改变标识。 这个有点哲学味道。/users/1代表用户1，不管他改名、换手机号、注销，这个URI始终是他。有人问：为什么不让URI"动态化"？答案是——URI是资源的身份证，不是它的当前状态。一旦允许URI随状态变化，缓存就全废了。
5. 无状态。 再强调一遍：每个请求自带认证信息，服务器不保留会话。为什么重要？因为这是系统能水平扩展的前提，也是DevOps最爱的特性——发布时不用等所有用户登出，服务器说换就换。