REST API 工作原理——一次请求的往返 · 思维导图
REST API 工作原理——一次请求的往返. 可编辑的思维导图，以彩色分支、子主题和曲线连接呈现想法。 曲线表示联系；只有方向重要时才使用箭头。
REST API 是一场用 HTTP 进行的对话：客户端发出一个指明资源与动作的请求，服务器处理它，响应则带回一个状态码和结果。
REST API 工作原理——一次请求的往返 · 思维导图
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
如何阅读这张思维导图
- 从中心主题开始，沿着彩色分支探索相关想法。
- 曲线表示联系；只有方向重要时才使用箭头。
Request
这一分支汇集 “The method is the verb — GET reads, POST creates, PUT replaces, PATCH updates, DELETE removes. REST names resources by URL and acts on them with these verbs.”, “Client sends the request over HTTPS”.
Routing
这一分支汇集 “The URL path is the routing key: /users/42 is the handler for one user. Query parameters, headers and the body carry everything else the handler needs.”, “Validation covers authentication (are you who you say you are?), authorization (are you allowed?), and the payload itself (is the data well formed?).”.
Business logic
这一分支汇集 “Handler runs the business logic”, “Server reads or writes the resource in the database”.
Response
这一分支汇集 “The status code is the contract: 200 OK, 201 Created, 204 No Content, 404 Not Found, 500 Server Error. Clients branch on it before they read the body.”, “Client receives the response and parses it”, “Client renders the result to the user”.
Errors
这一分支汇集 “Server returns 400 / 401 / 403”.
跨分支联系
REST 是一份用 HTTP 写成的契约：方法是动词，URL 是资源，状态码是机器可读的结果。
客户端是无状态的——每一个请求都自带服务器所需的一切，因此不需要共享会话。
校验就是安全边界；无效的请求会在任何业务逻辑运行之前被拒绝。
响应首先由它的状态码定义，其次才是它的响应体。
REST 流量跑在其他几张技术图解所描绘的同一套 DNS、HTTPS 与互联网基础设施之上。
Key relationships and takeaways
- REST 是一份用 HTTP 写成的契约：方法是动词，URL 是资源，状态码是机器可读的结果。
- 客户端是无状态的——每一个请求都自带服务器所需的一切，因此不需要共享会话。
- 校验就是安全边界；无效的请求会在任何业务逻辑运行之前被拒绝。
- 响应首先由它的状态码定义，其次才是它的响应体。
- REST 流量跑在其他几张技术图解所描绘的同一套 DNS、HTTPS 与互联网基础设施之上。
When to use this visual
- 在工程师设计第一个端点之前，先教会他们 HTTP 方法、URL 与状态码这套模型。
- 对照 REST 惯例审视一个 API 的契约——错误到底是用状态码表达，还是用 200 加一个标志位？
- 把关于幂等与缓存的讨论，落到请求究竟是怎样构造和校验的这件事上。
运作方式
调整中心主题
根据项目或课程修改中心主题的名称。
扩展分支
编辑想法并添加示例或注释。
连接相关想法
绘制跨分支连接；只有方向重要时才使用箭头。
常见问题
什么是 REST API？
REST API 是一组把系统资源暴露出来的 HTTP 端点。客户端用 HTTP 方法对资源操作——GET 读取，POST 创建，PUT 或 PATCH 更新，DELETE 删除——服务器则以一个状态码和一份表示形式作答，通常是 JSON。REST 是一种风格而不是标准，它的价值在于任何会说 HTTP 的客户端都能用它。
GET、POST、PUT 与 DELETE 有什么区别？
它们是 REST 契约里的动词。GET 读取一个资源，且不应有副作用。POST 创建一个新资源并返回它的标识。PUT 整体替换一个资源，并且是幂等的——重复执行不会再改变什么。PATCH 做局部更新。DELETE 删除一个资源。动词加上 URL 才共同指明完整的动作，这也是图中的请求方框把方法放在第一位的原因。
为什么状态码在 REST 里很重要？
因为它们是这次请求机器可读的结果。客户端不必解析响应体就能按状态码分支：2xx 成功，4xx 是客户端的错，5xx 是服务器的错。那些返回 200、却在响应体里塞一个错误标志的 API 破坏了这份契约，逼得每一个客户端都要为响应做特殊处理。
什么样的 API 才算“RESTful”？
实用的核对清单：用 URL 为资源命名，用 HTTP 方法表达动作，请求无状态（每一个都自带服务器所需的一切），响应正确使用状态码，往往还有超媒体或带版本的 URL。这张画布建模的就是那次往返——请求、校验、处理、响应——那正是每一次 RESTful 交互共有的形状。
在 QueryChart 中编辑此思维导图
在可编辑画布中打开思维导图。移动想法、添加分支并绘制连接。