我很抱歉，但你并不知道什么是 RESTful API。我知道你是一位经验丰富的开发者，已集成各种API，甚至可能在多种语言中生产了数十个。但这一切只证明了你遵循了行业的最佳实践并阅读了无数行文档，这很好。然而，这些都不能证明你对 RESTful 的了解。别慌！你并不孤单。我认识的大多数开发者也不能定义它、实现它或指出它的优势。这就是为什么在这篇文章中，我将用简单易懂的例子来解释它的优点。而且你可能在读完后将再也不会以同样的方式看待API。好吧，你被警告了！API RESTful 通常被用作 REST API（表示性状态转移）的同义词，而这种细微差别很重要。REST 不是一个HTTP接口：它是一种架构风格，由罗伊·费尔丁在他的博士论文（2000年）中定义，施加了一些约束：客户端-服务器架构：客户端和服务器必须分开。无状态：每个客户端请求必须包含理解和处理该请求所需的所有信息。换句话说，服务器不会在请求之间保存客户端的状态信息。可缓存：响应必须明确标记为可缓存或不可缓存。分层系统：架构可以由多层组成，每一层都有特定的功能，并彼此隔离。统一接口：客户端和服务器之间的通信必须是可预测的，具有明确定义的模式。按需代码（可选）：服务器可以向客户端发送可执行代码，例如 JavaScript 脚本，以扩展客户端的功能。换句话说，REST 是一套为服务资源而设定的架构原则，通常通过 HTTP 进行。这在Web开发中根深蒂固，并且如此标准化，以至于当我们没有看到它时，感觉会很奇怪。接下来是令人不安的部分：严格来说，REST 已经包括你将在此文中阅读的所有内容。超媒体是统一接口约束的一部分，“RESTful”只是形容词，意为“符合REST”。发生的事情是，流行用法一直在将“REST”贬低到仅仅意味着“返回 JSON 的 HTTP API”，如此严重以至于费尔丁本人在2008年发表了一篇著名文章《REST APIs 必须以超文本驱动》，抱怨我们将任何伪装成 HTTP 的 RPC 称为 REST。理查德森成熟度模型给出了这一距离的量化：第0级，一个单一的RPC风格的端点；第1级，有自己 URI 的资源；第2级，正确使用的 HTTP 动词和状态码；第3级，超媒体。你每天消费的绝大多数“REST” API 停留在第2级。在这篇文章中，我将使用RESTful来指代费尔丁所要求的第3级。目标是将API转变为可预测的、标准化的、自描述的接口。仅凭基础URL，客户端将能够探索每个资源，而无需借助外部文档。此外，我们将有灵活性来更改路由而不影响客户端，甚至可以玩多个通信协议。但首先你必须了解一个概念：HATEOAS（超媒体作为应用状态的引擎）。这个概念对于理解 RESTful API 如何可以自描述和可导航至关重要。HATEOAS（超媒体作为应用状态的引擎）超媒体是 RESTful 的关键特征之一：它允许客户端通过回复中提供的链接动态发现资源。它们通常以 _links 父节点为基础。{ "id": 123, "name": "约翰·多", "_links": { "self": { "href": "/users/123", "method": "GET" }, "update": { "href": "/users/123", "method": "PUT" }, "delete": { "href": "/users/123", "method": "DELETE" }, "friends": { "href": "/users/123/friends", "method": "GET" }, "posts": { "href": "/users/123/posts", "method": "GET" }, "search": { "href": "/search/?query={query}", "method": "GET", "templated": true } } } 由于这个特性，客户端可以通过解析和跟随链接来浏览 API，以获取所需的信息，类似于你浏览互联网的方式。此外，由于你使用名称作为标识符（对象键）在相对路由（href）之间跳转，后端可以在不影响客户端的情况下更改地址。这是非常强大的，因为客户端不受固定路由结构的限制；它在节点之间移动。请注意最后一个链接中使用了 templated: true。这表明 href 包含一个 URI 模板（遵循 RFC 6570），在使用之前必须填充特定值。它是一种优雅的方式来发现参数化的端点。例如，客户端可以用“restful api”替换 {query}，以搜索相关内容。在我们继续之前，诚实地说一下：_links 约定来自 HAL（超文本应用语言），但 HAL 并没有定义方法字段；