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