说明：如有侵权，请联系删除

HTTP方法的安全性和幂等性

HTTP 协议规定了不同方法的安全特性和幂等特性，作为服务提供者的服务器必须为客户端提供这些特性。

安全性（Safety）：
仅指该手段的多次调用不会产生副作用（即不会改变资源状态），不涉及传统意义上的“安全”。
安全的方法不会修改资源状态，尽管多次调用的返回值可能不同（例如资源被其他非安全手段修改过）。

幂等性（Idempotence）：
指该方法多次调用返回的效果（形式）一致，客户端可以重复调用并期望获得相同的结果。
幂等的含义类似于编程语言中的 setter 方法：一次调用和多次调用产生的效果一致，都是对一个变量进行赋值。

两者的区别容易混淆，简单理解如下：

特性判断标准示例
安全性否会改变资源状态（不会改变 → 安全）就是发送请求GET、HEAD、OPTIONS
幂等性否产生相同效果（不会改变 → 幂等）就是多次执行GET、PUT、DELETE、HEAD、OPTIONS

安全性与幂等性总结图

HTTP方法的安全性与幂等性

可以认为安全的方法都是只读方法（GET、HEAD、OPTIONS），不会改变资源状态，因此它们同时也是幂等的。

DELETE方法的幂等性

DELETE 方法的语义表示删除服务器上的一个资源。
第一次删除成功后资源就不存在了，资源状态发生了改变，因此DELETE 办法不具备安全性。

然而 HTTP 协议规定 DELETE 途径是幂等的：
每次删除该资源都要返回状态码 200 OK。

服务器端若要实现幂等的 DELETE 方法，必须记录所有已删除资源的元数据（Metadata），否则第二次删除时返回的响应可能是 404 Not Found，从而破坏幂等性。

PUT与POST的区别

PUT 和 POST 方法语义中都包含修改资源状态的意思，因此都不是安全的。

方法是否安全是否幂等特点
PUT否是重复执行结果相同（覆盖）
POST否否重复执行结果不同（新建）

为什么 PUT 是幂等的而 POST 不是？

HTTP 协议规定：

  • POST 方法：URL 指向资源的父级资源，待创建资源的ID 信息在请求体中携带。
    → 重复提交 POST 请求可能会创建多个不同资源。
  • PUT 方法：URL 直接指向待修改资源。
    → 重复提交 PUT 请求只会对该 URL 指定的资源起作用，也就是只会创建或更新一个资源。

因此：

  • PUT 是幂等的：多次调用的结果一致（更新或覆盖相同资源）。
  • POST 不是幂等的：多次调用可能产生多个不同资源。

PUT 与 POST 的使用区别

在实践中有几种常见观点：

  1. 用 POST创建资源，用PUT 更新资源；
  2. 用 PUT创建资源，用POST 更新资源；
  3. PUT 与 POST 都可用于创建或更新。

这些争论其实不是“风格”问题，而是“语义”问题。
是否启用 PUT 或 POST，取决于操作是否幂等。

“Methods can also have the property ofidempotencein that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.”

即：如果一个技巧重复执行多次，产生的效果是一样的，那么它就是幂等的。

举例说明

假设有一个博客体系提供一个 Web API：

http://superblogging/blogs/post/{blog-name}

发送一个 HTTP PUT 或 POST 请求，Body 中包含博文内容。

问题：该应用 PUT 还是 POST？

取决于服务的行为是否幂等：

  • 如果发送两次相同请求会生成两个不同的帖子 → POST（非幂等）
  • 如果后一个请求覆盖了前一个帖子 → PUT（幂等）

总结对比表

方法是否安全是否幂等典型用途
GET✅ 是✅ 是获取资源
HEAD✅ 是✅ 是获取资源元内容
OPTIONS✅ 是✅ 是查询支持的方法
POST❌ 否❌ 否创建子资源、提交表单
PUT❌ 否✅ 是创建/更新指定资源
DELETE❌ 否✅ 是删除资源

结论：

  • 安全性：不修改资源状态。
  • 幂等性：多次调用效果一致。
  • PUT 与 DELETE 是幂等但不安全；
  • GET、HEAD、OPTIONS 既安全又幂等；
  • POST 既不安全也不幂等。