概念论述
一个 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 办法不是幂等的。