HTTP、方法与 Web API

TL;DR（太长不看） HTTP 是 Web 的语言；它的动词（方法）就是让客户端和服务器相互理解的语法。选对动词，发送正确的请求头，你的 API 就能运转自如。无视规则，各种怪问题就会冒出来。本文解释其中的原因和方法——从原始请求字节，一直讲到 Divooka 中实用的可视化编程工作流。

1. 深入了解

我们已经介绍过使用和设计 REST API 的基础知识。现在我们来深入细节：

• 开发者将了解该使用哪种方法（GET、POST 等），以及为什么。
• 测试人员 / QA 将看到如何在 Postman/Insomnia 风格的节点图中重现真实世界的流量。
• 非开发人员的团队成员将对“安全”调用与“破坏性”调用建立直观认识（这样他们就不会再问“我们不能所有地方都用 POST 吗？”）。

2. HTTP 基础（10 分钟复习）

2.1 HTTP 究竟是什么？

• 一种无状态、基于文本的请求/响应协议，运行在 TCP 之上（HTTP/3 则运行在 QUIC 之上）。
• 一个连接 → 一个请求 → 一个响应（HTTP/2 中支持多路复用，但概念上是一样的）。

2.2 三层“三明治”

<Request / Status Line>
<Header 1: value>
<Header 2: value>
...
<BLANK LINE>
<Optional Body>

那个空行（\r\n\r\n）就是秘诀所在：它告诉所有人“请求头结束了，正文开始了”。

2.3 理解：安全性 • 幂等性 • 可缓存性

在使用 HTTP 方法时，了解三个影响请求行为的关键属性会很有帮助——尤其是在你构建流程、重试操作或缓存响应的时候。

🔹 安全方法

这些方法是只读的——它们不会更改服务器上的任何内容。你可以随意多次调用，而没有任何风险。

• 示例： GET、HEAD、OPTIONS
• 用途： 安全方法非常适合预取或检查数据，不会产生副作用。

🔹 幂等方法

这些方法可能会更改内容，但执行多次与执行一次的效果相同。

• 示例： GET、PUT、DELETE、HEAD、OPTIONS
• 用途： 非常适合重试——如果网络故障导致请求被重复发送，你也不会意外地创建或删除多个对象。

🔹 可缓存方法

对于这些方法，响应可以由浏览器或代理服务器安全地存储（缓存）。

• 示例： GET（最常见），有时也包括 HEAD
• 用途： 避免为相同的数据重复调用，让你的应用更快、更轻量。

快速总结：

属性	含义	常见方法
安全	不更改数据	GET、HEAD、OPTIONS
幂等	无论发送多少次，结果都相同	GET、PUT、DELETE、HEAD、OPTIONS
可缓存	响应可以被存储以便复用	GET（默认）、HEAD

3. 原始 HTTP 消息格式（纯文本示例）

查看原始文本对我们有以下帮助：

• 了解真实情况： Divooka 中所有好用的“HTTP Request”节点，最终都会转换为通过 TCP 发送的纯文本流（外加 \r\n 分隔符）。
• 强大的调试能力： 当出现问题时（例如请求头拼写错误或缺少空行），阅读原始消息可以帮助你准确找出问题所在。
• 学习的桥梁： 查看原始文本可以加深你对“请求行 → 请求头 → 空行 → 正文”如何对应到我们的可视化工具底层行为的理解。

3.1 原始 HTTP 请求剖析

示例：一个获取 JSON 资源的简单 GET 请求

GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
User-Agent: Divooka/1.0
Authorization: Bearer <token>

逐行解析：

1. GET /api/users/123 HTTP/1.1
   • 请求行： <METHOD> <PATH> <HTTP-VERSION>。
   • 这里，GET 请求获取 ID 为 123 的用户。
   • HTTP/1.1 告诉服务器我们使用的是哪个版本的协议。
2. Host: api.example.com
   • 在 HTTP/1.1 中是必需的，以便服务器知道你要访问的是哪个虚拟主机——当一台服务器托管多个域名时，这一点尤其重要。
3. Accept: application/json
   • “请返回 JSON。”如果省略，服务器通常会默认返回 HTML 或它自己的默认格式。
4. User-Agent: MyVisualTool/1.0
   • 标识客户端。Postman 或 Divooka 会发送类似 PostmanRuntime/7.28.4 的值。
5. Authorization: Bearer <token>
   • 发送 JWT 或 OAuth 2.0 令牌的常用方式。
6. （空行）
   • CRLF CRLF 分隔符： 两个连续的 \r\n 序列标志着请求头的结束。如果没有它，服务器会一直等待更多的请求头行！
7. （后面没有正文，因为 GET 通常不发送正文。）

3.2 原始 HTTP 响应剖析

示例：服务器对该 GET 请求的响应

HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 14:35:22 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 111
Cache-Control: no-cache, no-store
ETag: "5f4dcc3b..."

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com",
  "created_at": "2025-05-20T08:15:00Z"
}

注意 Content-Length 必须等于 111 字节（即 JSON 负载的确切长度）。如果服务器使用 chunked（分块）编码以流式方式发送，它会省略 Content-Length，转而发送带有大小前缀的数据块。

逐行解析：

1. HTTP/1.1 200 OK
   • 状态行： <HTTP-VERSION> <STATUS_CODE> <REASON_PHRASE>。
   • 这里，200 OK 的意思是“成功，这是负载”。
2. Date: Mon, 02 Jun 2025 14:35:22 GMT
   • 服务器的时钟。当你需要比较时间戳请求头或调试超时问题时很有用。
3. Content-Type: application/json; charset=utf-8
   • 告诉客户端如何解释正文。如果你的 Divooka 流程期望的是 text/html，你就会知道哪里出了问题。
4. Content-Length:1117
   • 随后正文的确切字节长度。如果没有它（或分块编码），客户端将无法知道正文在哪里结束。
5. Cache-Control: no-cache, no-store
   • 指示中间方（浏览器、CDN）不要缓存此响应。
6. ETag: "5f4dcc3b5aa765d61d8327deb882cf99"
   • 资源这一特定版本的标识符。之后，客户端可以在 GET 请求中发送 If-None-Match: "<etag>" 来检查数据是否已更改。
7. （空行）
   • 表示“请求头结束了”。接下来的字节属于正文。
8. 正文： 原始 JSON 负载，长度恰好为 97 字节（包括空白字符和换行符）。

{
"id": 123,
"name": "Alice",
"email": "[alice@example.com](mailto:alice@example.com)",
"created\_at": "2025-05-20T08:15:00Z"
}

3.4 发送带 JSON 正文的原始 POST 请求

下面是一个更详细的示例，展示带有 JSON 负载的 POST /contacts 在纯文本中是什么样子。请注意，Content-Length 请求头必须与正文的字节数一致（包括花括号、引号和换行符）。

POST /api/contacts HTTP/1.1
Host: api.example.com
User-Agent: MyVisualTool/1.0
Content-Type: application/json
Content-Length:  84
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...

{
  "first_name": "Bob",
  "last_name": "Smith",
  "email": "bob.smith@example.com"
}

• 请求头部分： • 前五行都是请求头或请求行。 • 空行之后的所有内容都是正文。 • 服务器在该空行之后恰好读取 84 个字节——不多也不少。
• 正文部分： • JSON 负载在语法上必须有效（逗号、引号、花括号都要正确配对）。 • 如果你不小心输入了 Contnt-Length: 85，服务器会多等待一个字节，或者可能拒绝你的请求。

3.5 “分块”传输编码是什么样子

有些服务器会把较大的正文分成多段（“块”）发送，这样就不需要预先知道 Content-Length。分块响应看起来是这样的：

HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 15:00:00 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked

1f      <– hex length of first chunk: 31 bytes
{"page":1,"per_page":10,"total":42}
2a      <– hex length of next chunk: 42 bytes
{"data":[{"id":1,...},{"id":2,...},...]}
0       <– “0” means “no more chunks”

• 分块编码的工作方式：
  1. 服务器发送一个十六进制数（例如 1f），后跟 \r\n。这告诉你“接下来有 31 个字节”。
  2. 然后是接下来的 31 个字节数据（例如那个小 JSON 对象），后跟 \r\n。
  3. 然后是另一个十六进制数（2a = 42 字节），依此类推。
  4. 最后的 0\r\n\r\n 表示“全部发送完毕，谢谢”。
• 分块编码为什么重要： • 你的 Divooka “HTTP Request”节点通常会隐藏这些细节，但如果你使用纯文本的“Raw Socket”节点，就会看到这些数据块一一传过来。 • 分块响应不包含 Content-Length 请求头。客户端必须不断重组数据块，直到遇到长度为零的块为止。

3.6 常见陷阱

失误	症状	解决方法
忘记空行	立即返回“400 Bad Request”	在请求头之后添加 \r\n\r\n
Content-Length 错误	连接挂起或内容被截断	让你的客户端/工具来计算它
换行符混用（只有 \n）	部分服务器会拒绝	在原始模式下始终使用 \r\n

4 CRUD 与 HTTP 方法

CRUD 代表：

• Create（创建）：添加新的记录或资源（例如创建用户账户）。
• Read（读取）：检索或查看现有数据（例如获取用户的个人资料）。
• Update（更新）：修改现有数据——要么完全替换，要么只更改某些字段。
  • 整体更新替换整个资源。
  • 部分更新只更改指定的字段。
• Delete（删除）：从系统中移除记录或资源。

CRUD	典型方法	为什么这样搭配
Create	POST	非幂等；由服务器选择新的 URI
Read	GET（或 HEAD）	安全且可缓存
Update-whole	PUT	幂等的完整替换
Update-partial	PATCH	幂等的字段级更改
Delete	DELETE	幂等的删除

4.1 当 CRUD 不适用时

• 登录/登出——POST /auth/login、POST /auth/logout
• 复杂操作——POST /payments/{id}/capture
• 批量操作——POST /users/bulk_delete，附带一个由 ID 组成的 JSON 数组

5 逐个方法详解

下面的每一节都遵循相同的结构：

语义 • 幂等性 / 安全性 • 典型状态码 • Divooka 示例 • 常见陷阱

5.1 GET

• 安全 + 幂等 + 可缓存
• 状态码 200 OK、304 Not Modified。
• Divooka：拖入一个 Send (HTTP) Request 节点 → Method = GET → URL = {{base}}/users?active=true → 连接到 Preview JSON。
• 陷阱：不要在 GET 中修改数据（“这只是一个无害的跟踪像素！”……直到广告拦截器删掉你一半的数据库）。

5.2 POST

• 创建或处理；默认不是幂等的。
• 状态码 201 Created（新的 URI 位于 Location 请求头中）或 200 OK。
• Divooka：添加一个 Text 或 (YAML) To JSON 节点，选择 POST /users，正文为 {"name": "Bob"}。
• 陷阱：在缓慢的 Wi-Fi 上重复提交付款表单 → 被扣款两次。请使用 Idempotency-Key 请求头或在后端去重。

5.3 PUT

• 对给定 URI 处的资源进行完整替换。幂等。
• 状态码 200 OK（有正文）、204 No Content（无正文）。
• Divooka：对 /users/123 发送 PUT 请求，附带完整的用户对象（JSON 格式）。
• 陷阱：只发送已更改的字段——服务器会把缺失的字段覆盖为 null。

5.4 PATCH

• 部分更新；如果实现合理，则是幂等的。
• 正文可以是“merge patch”（只包含已更改的字段），也可以是 RFC 6902 JSON Patch。
• Divooka：使用 Text 节点编写部分 JSON → 对 /users/123 发送 PATCH 请求，正文为 {"email": "new@x.com"}。
• 陷阱：客户端和服务器对补丁格式的理解不一致 → 415 Unsupported Media Type。

5.5 DELETE

• 删除资源；幂等。
• 状态码 204 No Content（成功）、404 Not Found（已不存在）。
• Divooka：使用 DELETE 的 Send Request 节点 → 把状态码传入 Branch：如果是 204，显示“已删除”，否则记录错误。
• 陷阱：未经身份验证的删除（糟糕！）。

5.6 HEAD

• 类似 GET，但只返回响应头。
• 用于探测资源是否存在或获取元数据（Content-Length、Last-Modified）。
• Divooka：对 /videos/intro.mp4 发送 HEAD 请求 → 如果 Content-Length > 10 MB，则改为流式传输缩略图。

5.7 OPTIONS

• “我在这里能做什么？”——返回 Allow 响应头和 CORS 规则。
• 对浏览器的预检请求（Access-Control-Request-Method）至关重要。
• Divooka：对 /users 发送 OPTIONS 请求 → 解析 Allow，动态启用/禁用按钮。
• 陷阱：服务器忽略 OPTIONS → 跨域 JS 就要哭了。

5.8 较少见的方法（TRACE、CONNECT、自定义方法）

• TRACE——回显请求（用于调试；通常被禁用）。
• CONNECT——隧道（通过代理传输 TLS）。
• 自定义方法——例如 WebDAV 的 PROPFIND、REPORT。Divooka 可以在方法字段中发送任意标记。

6. 状态码及其“伙伴”

状态码	动词	含义	Divooka 提示
200 OK	GET/PUT/PATCH	成功，有正文	在 JSON 查看器中查看
201 Created	POST	资源已创建；见 Location	将响应头提取到变量中
204 No Content	PUT/PATCH/DELETE	成功，无正文	跳过 JSON 解析
301/302	任意	重定向，会改变 GET/POST 规则	自动跟随？在节点中切换
307/308	任意	重定向，保留方法	适用于 PUT → PUT
400	任意	语法/正文错误	显示错误提示
401/403	任意	身份验证失败 / 禁止访问	刷新令牌逻辑
404	任意	未找到	重试？可能没用
405	任意	方法不被允许	你选错了动词
500/503	任意	服务器故障 / 过载	添加重试/退避循环

7 最佳实践与常见陷阱

1. 选择正确的动词——代理、缓存、SDK 生成器都依赖于它。
2. 设置 Content-Type 和 Accept——自动检测只是个神话。
3. 对有风险的 POST 请求（付款、注册）使用幂等键。
4. 处理 CORS——如果浏览器会调用你的服务，就要支持 OPTIONS。
5. 礼貌地为 API 做版本管理——通过路径（/v2/users）或请求头（Accept-Version），不要在半途中给方法赋予额外的含义。
6. 保护破坏性的动词——PUT/PATCH/DELETE 要求身份验证。
7. 安全地并行化——GET 可以并发执行；而针对同一资源竞争的两个 PUT 应当串行执行或使用 ETag。

8 高级主题（可选，供提前阅读）

• HATEOAS——响应中包含后续可执行的操作（带有方法提示的 _links）。
• 条件请求——使用 If-None-Match、If-Match 节省带宽并避免更新丢失。
• HTTP/2 多路复用——一个连接中可以有多个请求；方法保持不变。
• GraphQL 与 REST——所有请求都是 POST，但缓存转而依赖查询哈希。
• Webhook——它们只是反方向的 POST；设计接收方时，请遵循你对客户端所期望的同样的动词规范。

9 融会贯通：端到端示例场景

下面是三个贴近实际的工作流，每个都拆分为清晰的步骤，展示不同的 HTTP 方法如何在单个流程中协同工作。可以把每一步看作 Divooka 中的一个节点：你选择的方法决定了接下来会发生什么。在这些场景之后，我们会简要看看如何把其中一个场景映射为一个简单的可视化管道。

9.1 场景 A：用户注册流程

假设一位新用户正在你的网站上注册。你需要防范跨站攻击、创建账户、确认对方的电子邮件，最后让对方更新个人资料。整个过程如下：

1. 获取 CSRF 令牌（GET /csrf-token）。 首先，客户端发送一个 GET /csrf-token 请求。服务器在正文中返回一个令牌（例如 { "csrf_token": "abc123" }）。在 Divooka 中，这可能是一个 GET 节点，连接到一个“存储令牌”节点，后者把 csrf_token 保存到一个变量中。

2. 提交注册表单（POST /register）。 接下来，客户端发送一个 POST /register 请求，正文为类似下面的 JSON：

   {
     "username": "jane_doe",
     "email": "jane@example.com",
     "password": "s3cur3",
     "csrf_token": "abc123"
   }
   

   如果一切有效，服务器会返回状态码 201（Created），可能还会附带一条“请验证你的电子邮件”的消息。在 Divooka 中，你会使用一个 POST 节点，带上 X-CSRF-Token 或将其放入 JSON 中，然后把响应路由到一个“检查状态”节点。如果是 201，就继续；如果是 400，就显示错误。

3. 轮询电子邮件验证状态（GET /verify?token=…）。 注册之后，用户点击电子邮件中的链接（类似 /verify?token=xyz）。客户端可以通过反复发送 GET /verify?token=xyz 来模拟轮询。每次，服务器可能会这样回复：

   • 在用户点击真正的链接之前，回复 200 OK { "verified": false }
   • 用户点击之后，回复 200 OK { "verified": true } 在 Divooka 中，你可以使用一个循环：由一个 GET 节点检查 response.body.verified；如果为 false，等待几秒后重试（最多重试一定次数）；如果为 true，则继续。

4. 更新新用户的个人资料（PATCH /users/）。 账户验证通过后，客户端发送 PATCH /users/123（假设服务器返回了 id = 123），正文例如：

   { "display_name": "Jane Doe", "avatar_url": "https://..." }
   

   这个部分更新让用户可以个性化自己的账户。服务器返回 200 OK 以及更新后的用户对象。在 Divooka 中，一个 PATCH 节点读取已存储的 id 并发送 JSON 补丁。如果成功，就显示“欢迎，Jane！”；如果失败，错误处理程序就会介入。

9.2 场景 B：库存管理

假设你经营一个电子商务网站，需要让仓库数据保持同步。你希望列出所有商品、更新库存数量、删除已售罄的产品，并批量添加新产品。下面是一种直接的做法：

1. 获取当前商品（GET /items）。 客户端发送 GET /items，服务器返回一个 JSON 数组：

   [
     { "id": 101, "name": "Widget A", "quantity": 5 },
     { "id": 102, "name": "Widget B", "quantity": 0 },
     { "id": 103, "name": "Widget C", "quantity": 12 }
   ]
   

   在 Divooka 中，一个 GET 节点连接到一个“For Each”节点，后者遍历 response.body 中的每个商品。

2. 在需要时更新数量（PUT /items/）。 对于任何库存发生变化的商品——例如 Widget A 从 5 变为 3——你发送：

   PUT /items/101
   {
     "id": 101,
     "name": "Widget A",
     "quantity": 3
   }
   

   在 Divooka 中，每次循环迭代都会检查 quantity 是否需要调整；如果需要，就调用一个 PUT 节点，并传入完整的商品对象。成功后，服务器回复 200 OK 或 204 No Content。

3. 删除已售罄的商品（DELETE /items/）。 如果 quantity 为 0（比如 Widget B），客户端就发送 DELETE /items/102。服务器回复 204 No Content，表示“商品已删除”。在 Divooka 中，同一个 For Each 循环中可以包含一个条件判断：如果 quantity == 0，就调用 DELETE 节点；否则跳过。

4. 批量添加新商品（POST /items/bulk）。 最后，要一次添加多个新产品，只需发送一个请求：

   POST /items/bulk
   {
     "items": [
       { "name": "Widget D", "quantity": 20 },
       { "name": "Widget E", "quantity": 15 }
     ]
   }
   

   服务器返回 201 Created 以及新 ID 的列表：

   { "created": [ { "id": 104 }, { "id": 105 } ] }
   

   在 Divooka 中，这只需要一个 POST 节点，再配合一个遍历你的“newItems”列表的 JSON Builder。成功之后，你可以记录一份摘要，或者显示一条“批量添加完成”的消息。

9.3 场景 C：自动化错误处理与重试逻辑

当服务繁忙时，你不希望整个流程崩溃。相反，应当通过重试来处理 503 Service Unavailable，如果仍然失败再发出警报。下面是一个简单的模式：

1. 初始请求（GET /health-check）。 首先发送 GET /health-check。服务器通常返回 200 OK { "status": "healthy" }。在 Divooka 中，把响应路由到一个检查 statusCode 的“Switch”节点。

2. 如果遇到 503，暂停后重试。 如果 statusCode == 503，使用一个设置为 5000 毫秒（5 秒）的“Delay”节点，然后循环回到同一个 GET 节点。记录重试次数——尝试 3 次后停止。在 Divooka 中，这可能是一个小的子流程，其中有一个变量 retryCount，每次遇到 503 时递增。

3. 如果重试后仍然失败，发送警报（POST /alerts）。 当 retryCount 达到 3 而你仍然收到 503 时，转到一个 POST /alerts 节点，正文为：

   {
     "message": "Health check still failing after 3 retries.",
     "timestamp": "2025-06-02T15:00:00Z"
   }
   

   服务器回复 201 Created。在 Divooka 中，你可以把它连接到一个“Notification”节点，通过电子邮件发送或记录该问题。

4. 只要有一次 GET 成功（200），就继续正常流程。 一旦从 GET /health-check 收到 200 OK，就跳出重试，继续执行其他任务（例如定时数据获取或关键更新）。在 Divooka 中，这只是 Switch 节点针对 statusCode == 200 的另一个分支。

9.4 示例管道示意图（过程式上下文）

下面粗略展示了场景 B 在 Divooka 中可能的样子。每个方框代表一个节点，箭头表示数据流。每个节点中的方法（GET/PUT/DELETE/POST）决定了你是在获取、更新、删除还是创建数据。

[Start]
   ↓
[GET /items]            ← Fetch list of items
   ↓
┌───────────────┐
│For Each item │────────────────────────────────────────────────────╮
└───────────────┘                                                │
   ↓                                                            │
[Check quantity]                                                │
   ↓                                                            │
[quantity > 0?] ─ No─▶[DELETE /items/{id}] ──→(Log “Deleted”)   │
   ↓ Yes                                                        │
[quantity changed?] ─ No─▶(Skip update)                         │
   ↓ Yes                                                        │
[PUT /items/{id}] ──→(Log “Updated”)                            │
   ↓                                                            │
   ⤵─────────────────────────────────────────────────────────────────┘
   ↓
[Collect results]
   ↓
[POST /items/bulk]   ← Add new items
   ↓
[Show “Done” Message]
   ↓
[End]

1. GET /items 节点获取所有商品。
2. 对响应中的每个商品进行循环（For Each item）。
3. 一个 Decision 节点检查是否 quantity == 0。
   • 如果是，调用 DELETE /items/ 并记录成功。
   • 如果不是，检查 quantity 是否发生了变化。
     • 如果有变化，调用 PUT /items/ 进行更新并记录。
     • 否则什么也不做，继续下一个。
4. 循环结束后，管道收集你想要添加的所有新商品，并以一个批次发送 POST /items/bulk。
5. 最后，一个节点显示“Done”或写入日志。

实践要点

• 你可以看到每个 HTTP 方法如何各司其职——只在 quantity == 0 时使用 DELETE，只在需要更改时使用 PUT，只在批量创建时使用 POST。
• Divooka 的可视化模型让这些分支和循环变得直观：你只需拖放添加一个判断节点，选择你的变量（比如 quantity），然后连线即可。
• 结合场景 C 中的 Switch、Delay 和重试计数器，你可以优雅地处理错误：重试几次，然后发出警报。

把这些示例当作模板来使用。换成你自己的端点，调整请求头，让 Divooka 来完成插入正确的空行、计算 Content-Length、路由成功与失败路径等繁重工作。需要调试时，可以逐步进入程序流程查看中间结果，或者使用底层节点并粘贴确切的 HTTP 文本，观察请求头和正文是如何在网络上传输的。

10 速查参考

方法	安全	幂等	成功状态码	典型用途
GET	✔	✔	200, 304	读取数据
HEAD	✔	✔	200	读取响应头
POST	✘	✘	201, 200	创建 / 操作
PUT	✘	✔	200, 204	替换资源
PATCH	✘	✔	200, 204	部分更新
DELETE	✘	✔	204, 200	删除资源
OPTIONS	✔	✔	200	能力探测 / CORS

11 关键要点

• HTTP 在网络上传输的只是文本——掌握原始格式，你就能调试任何问题。
• 方法的选择会影响缓存、重试、安全，甚至在按请求计费的方案中影响费用。
• Divooka（或任何其他工具）会自动处理请求头、空行和 Content-Length，但了解底层原理能让你从用户变成高手。
• 拿不准时：GET 用于读取，POST 用于创建，PUT/PATCH 用于更新，DELETE 用于删除。 如果你要打破这条规则，请给出有文档记录的理由。

后续步骤

1. 启动 Divooka，创建一个名为 “Method Playground” 的新工作区文档
2. 重建上面的示例——切换到原始模式，观察传输的字节。
3. 试着在 POST 请求中添加一个 Idempotency-Key 请求头，然后单击“Run”五次。记下你的服务器做了什么。
4. 收藏本文。将来那个盯着一个莫名其妙的 405 发呆的你会感谢你的。

参考资料

• 知识库中关于 REST API 的文章。
• Divooka Web API 测试示例。