很多开发者觉得自己写的API是RESTful的，理由很简单：用了JSON、用了HTTP方法、路径也设计得挺规整。但在Leonard Richardson看来，这些可能只是表象。他提出的Richardson成熟度模型（RMM），给API的"REST纯度"划了一条从Level 0到Level 3的刻度线。

这个模型本质上是一套打分系统。Level 0是RPC-over-HTTP，也就是把HTTP当传输管道用；Level 3才是真正的超媒体驱动。大多数API其实都卡在中间某个位置，离"完全RESTful"还有距离。

打开网易新闻 查看精彩图片

REST不只是JSON加HTTP

新手常犯的一个误解，是以为"返回JSON、走HTTP协议"就等于REST。实际上，REST由六项架构约束共同定义，缺一不可。

第一项是关注点分离。客户端只负责界面和用户体验，服务端管数据和安全性，两边可以独立演进。第二项是统一接口——资源用URL标识（比如/users/5），用标准HTTP方法操作（GET、POST、PUT、DELETE），消息自包含。这套规则让API变得可预测、可互操作。

第三项是无状态。服务端不在请求之间"记住"任何东西，每个请求都得自带处理所需的全部信息。这是大规模扩展和可靠性的前提。第四项是缓存——正因为无状态会导致重复计算成本高，资源需要声明自己能否被缓存，把数据放进易失性存储，避免服务端反复做同样的活。

分层与按需代码

第五项是分层系统。Web层、应用层、数据库层各司其职，客户端根本不知道自己在跟真实服务器说话，还是跟代理、负载均衡器或网关打交道。这种"幕后"结构让扩展成为可能。

第六项是按需代码，也是唯一可选的约束。服务端可以通过发送可执行代码来扩展客户端功能，但实际生产环境用得很少。它属于REST家族的一员，但不是每个系统都需要。

看完这六条约束，再回头看自己的API，可能很多人会意识到：自己做的只是"长得像REST"的东西。

Level 3才是REST的完全体

用Richardson成熟度模型衡量，Level 3的API才真正像网站一样可导航。客户端不需要硬编码路由，而是跟着服务端返回的链接走。这意味着后端可以自由演进，不会因为改了URL结构就把前端搞崩——这才是REST设计的初衷。

如果你的API停在Level 2，其实也不用太焦虑。大多数API都在这层，已经算"良好实践"了。但要想拥抱完整的REST愿景，目标应该是Level 3。超媒体不是个花哨的术语，它是构建真正有韧性、可适应API的关键。

所以，你的API真的RESTful吗？用这个模型自测一下，答案可能比你想象的要诚实。