共计 839 个字符，预计需要花费 3 分钟才能阅读完成。
概念论述
一个 HTTP 办法是 幂等 的，指的是同样的申请被执行一次与间断执行屡次的成果是一样的，服务器的状态也是一样的。换句话说就是，幂等办法不应该具备副作用（统计用处除外）。所有的 safe 办法也都是幂等的。
幂等性只与后端服务器的理论状态无关，而每一次申请接管到的状态码不肯定雷同。须要留神的是，服务器不肯定会确保申请办法的幂等性，有些利用可能会谬误地突破幂等性束缚。
Safe（平安）
如果说一个 HTTP 办法是 平安 的，是指这是个不会批改服务器的数据的办法。也就是说，这是一个对服务器只读操作的办法。这些办法是平安的：GET，HEAD 和 OPTIONS。所有平安的办法都是 idempotent 的，但并非所有幂等办法都是平安的，例如，PUT 和 DELETE 都是幂等的，但不是平安的。
剖析图表
| HTTP Method | Idempotent 幂等 | Safe 平安 |
|---|---|---|
| OPTIONS | ✔️ | ✔️ |
| HEAD | ✔️ | ✔️ |
| GET | ✔️ | ✔️ |
| POST | ❌ | ❌ |
| PUT | ✔️ | ❌ |
| PATCH | ❌ | ❌ |
| DELETE | ✔️ | ❌ |
为什么 put 和 delete 是幂等，而 patch 则是非幂等的？
PUT【幂等】
PUT /user/1 #批改 id 为 1 的 user 的全副信息用于更新资源，没有的话则执行创立操作。每次执行申请时都会先判断一下序号为 1 的 User 信息是否存在，不存在则创立，否则视为更新。很显然，申请携带的数据每次都是一样的，所以不管申请多少次，最终的后果都是后盾存在这么一个资源（同内容笼罩式的更新或创立资源）。
PATCH【非幂等】
PATCH /user/1/house/3 #给 id 为 1 的 user 减少 3 个大房子用于更新资源，即数据实体的一部分属性（部分批改），该数据必然存在，否则失去更新意义。每次执行申请时都会先判断一下序号为 1 的 User 信息是否存在，存在则更新数据信息。依据 URL，咱们须要解决的是将 User 的 house 属性减少 3，很显然，屡次申请时会反复减少，而无奈放弃为一个确定的值。PATCH 处于不可控的位置，所以说 PUT 办法是幂等的，而 PATCH 办法不是幂等的。