关于 RESTful 幂等性，尤其是PUT，PATCH和DELETE

$为什么put和delete是幂等，而patch则是非幂等的？$

这里前提是首先要了解 RESTful API http 动词含义 。

幂等概念：
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。

通俗点说：重复发送同一个http请求多次，结果同发送一次。即不会产生任何副作用（数据资源的改变）。

这里举例子，以 flowers – 花 为资源实体进行说明：

 GET /flowers   #获取 花（flowers） 列表信息
 GET /flowers/1   #获取 某个具体的花（flowers） 列表详情

get【幂等】： 用于获取资源，无路是获取花的列表总信息还是某个具体的花的详情，不管调用多少次接口，返回结果总是保持不变的，不会改变任何资源。因为你没做任何改动操作，如：增、删、改。仅仅只是查询而已。

 POST /flowers   #新增 一种花（flowers） 的信息

post【非幂等】：用于创建资源，每次调用都会创建一个新的资源。理论上不会（实际也不应该，最起码存在主键）产生重复。每次调用都是新增一种花的信息，调用一次请求数据库就多了一种资源（resource）。

$重点来了$，put 和 patch 都是用于更新数据资源的。 区别 在于

put 做更新操作时候是提交一整个更新后的实体（即全部），而不是需要修改的实体中的部分属性。当 URI 指向一个存在的资源，服务器要做的事就是查找并替换。

patch 做更新操作的时候是请求中的实体是一组将要应用到实体的更改（即部分），而不是像 PUT 请求那样是要替换旧资源的实体。可以理解为：PATCH 请求中的实体保存的是修改资源的指令，该指令指导服务器来对资源做出修改。

怎么理解呢？要明白并理解 RESTful 核心就是 面向资源编程，如下：

 PUT /flowers/1   #修改 序号为1的花（flowers） 的全部信息

put【幂等】：用于更新资源，没有的话则执行创建操作。每次执行请求时都会先判断一下序号为1的花信息是否存在，不存在则创建，否则视为更新。很显然，请求携带的数据每次都是一样的，所以不论请求多少次，最终的结果都是后台存在这么一个资源（创建或更新）。

 PATCH /flowers/1/variety/lily/num/331   #假设url采用pathinfo模式，修改 序号为1的花（flowers） 的品种信息为百合，数量修改位431朵

patch【非幂等】：用于更新资源，即数据实体的一部分属性，该数据必然存在，否则失去更新意义。每次执行请求时都会先判断一下序号为1的花信息是否存在，存在则更新数据信息，这里有两个属性要改，做的处理可能是这样的：品种（variety）直接改为百合（lily），而数量（num）假设原本存在100朵，我们要修改到 431 朵，所以增加 331 朵。很显然，多次请求时，会重复增加 331 ，属性数量就无法保持 431 。而 PUT 请求不论执行多少次，属性数量永远都是 431 ， PATCH 则会改变，处于不可控的地位，所以说 PUT 方法是幂等的，而 PATCH 方法不是幂等的。

 DELETE /flowers/1   #删除 序号为1的花（flowers） 的全部信息

delete【幂等】： 用于删除资源，会将资源从后台删除。每次执行请求时都会先判断一下序号为1的花信息是否存在，存在则删除，否则不做任何操作。很显然，无论执行多少次资源的状态总是被删除的，不会有其它副作用的影响。

这里额外要注意的一点是，资源是一个实体，所有请求时应当为名词形式，并且是复数格式。