HTTP 方法参考
真正塑造 API 设计的四个属性 — safe（无服务端副作用）、idempotent（N 次重复相同最终状态）、cacheable（响应可重用）和 body-bearing（请求与响应）— 按方法整理，并附每个方法适用场景的一行简介。
Retrieve a representation of a resource. Should have no side effects.
- Safe
- 是
- 幂等
- 是
- 可缓存
- 是
- Req body
- 否
- Res body
- 是
Like GET but with no response body. Used to inspect headers (size, ETag, Last-Modified).
- Safe
- 是
- 幂等
- 是
- 可缓存
- 是
- Req body
- 否
- Res body
- 否
Submit data to the server — create a new resource, send a form, or trigger a side-effecting action. Cacheable only when explicit Cache-Control / Expires headers permit.
- Safe
- 否
- 幂等
- 否
- 可缓存
- 条件
- Req body
- 是
- Res body
- 是
Replace the target resource entirely with the request payload. Calling it twice gives the same result as once.
- Safe
- 否
- 幂等
- 是
- 可缓存
- 否
- Req body
- 是
- Res body
- 是
Remove the target resource. Idempotent in the same sense as PUT — deleting an already-gone resource still ends with the same state.
- Safe
- 否
- 幂等
- 是
- 可缓存
- 否
- Req body
- 条件
- Res body
- 是
Apply a partial update to the resource. RFC 5789 leaves the patch format up to the API — JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7396) are the common choices.
- Safe
- 否
- 幂等
- 否
- 可缓存
- 否
- Req body
- 是
- Res body
- 是
Ask what the server supports for the target — methods, CORS preflight, accepted Content-Types. The response usually carries an Allow header.
- Safe
- 是
- 幂等
- 是
- 可缓存
- 否
- Req body
- 否
- Res body
- 是
Echo back the request as the server sees it after proxies. Usually disabled in production for security (Cross-Site Tracing).
- Safe
- 是
- 幂等
- 是
- 可缓存
- 否
- Req body
- 否
- Res body
- 是
Establish a tunnel to the server, used by HTTP proxies for HTTPS. The client and server exchange raw bytes after the proxy accepts.
- Safe
- 否
- 幂等
- 否
- 可缓存
- 否
- Req body
- 否
- Res body
- 否
"条件"表示属性仅在显式头部（POST 的 Cache-Control、DELETE 的 body）下成立。
使用方法
- 输入方法名 (`patch`) 或关键字 (`cache`、`tunnel`) 来过滤。
- 阅读每个方法的卡片：顶部为描述，下面是五个属性圆点。
- 点复制把方法插入到你的 fetch 调用或 curl 命令中。
常见问题
- POST 也能做，为什么 PATCH 有独立方法？
- 语义。PATCH 意为"应用此部分 diff"；POST 为"创建或处理该负载"。如果你的 patch 格式设计得当，调用两次 PATCH 后资源状态与一次相同；这种幂等性保证值得多出一个动词。
- POST 真的能缓存吗？
- 有条件 — RFC 9111 §3 允许在响应携带显式 `Cache-Control` / `Expires` 头时缓存 POST 响应。实际上几乎没人这么做，因此多数缓存把 POST 视为不可缓存。
- 第二次调用返回 404，DELETE 还算幂等吗?
- 仍然算。幂等描述的是请求之后服务器的状态，而不是返回的状态码。删一次，资源没了；再删一次，它依然没有——最终状态相同，404 只是在陈述一个已经成立的事实。第一次返回 200、第二次没有任何变化仍返回 200 的 PUT，道理也一样。
- 搜索条件太长放不进 URL，要改用 POST 吗?
- 把搜索表达得最贴切的是 GET：安全、可缓存、可分享。但服务器、代理和日志对 URL 长度都有现实上限，放进 URL 的筛选条件还会被沿途每一份访问日志记下来。当条件确实很长或涉及敏感信息时，POST 是务实的选择，代价是失去缓存，也失去一个可以发给同事的链接。
相关工具
HTTP 头部参考
约 50 个标准 HTTP 请求、响应、CORS、缓存、安全、Cookie 头部的可搜索参考。
HTTP 状态码参考
可搜索的全部 HTTP 状态码（1xx-5xx）参考 — 含概要、RFC、使用时机与常见陷阱。
Base64 编码 / 解码
即时将文本编码为 Base64，或将 Base64 解码为文本。
HTTP Cookie 解析器
粘贴 `Cookie:` 请求头或 `Set-Cookie:` 响应头，查看每个 cookie 的名称、值、属性和警告。
ASCII 码表
256 行 ASCII / 扩展 ASCII 表 — 十进制、十六进制、八进制、二进制，以及控制字符名称。可搜索、可复制。
MIME 类型查询
用扩展名查 MIME 类型（或反向），并了解每种类型的用途。