首先,一些定义:

PUT在第9.6节RFC 2616中定义:

PUT方法请求将所包含的实体存储在提供的Request-URI下.如果Request-URI引用已经存在的资源,则封闭的实体应该被视为驻留在源服务器上的实体的修改版本.如果Request-URI未指向现有资源,并且该URI能够被请求用户代理定义为新资源,则源服务器可以使用该URI创建资源.

PATCH在RFC 5789中定义:

PATCH方法请求将请求实体中描述的一组更改应用于Request-URI标识的资源.

另外根据RFC 2616第9.1.2节, PUT是幂等的,而PATCH则不是.

现在让我们来看一个真实的例子.当我/users使用数据进行POST {username: 'skwee357', email: 'skwee357@domain.com'}并且服务器能够创建资源时,它将响应201和资源位置(假设/users/1),并且/users/1将返回对GET的任何下一次调用{id: 1, username: 'skwee357', email: 'skwee357@domain.com'}.

现在假设我要修改我的电子邮件.电子邮件修改被视为"一组更改",因此我应该修补/users/1 " 补丁文档 ".在我的情况下,它将是一个json {email: 'skwee357@newdomain.com'}.然后服务器返回200(假设权限正常).这让我想到第一个问题:

• PATCH不是幂等的.它在RFC 2616和RFC 5789中也这么说.但是如果我发出相同的PATCH请求(使用我的新电子邮件),我将获得相同的资源状态(将我的电子邮件修改为所请求的值).为什么PATCH不是幂等的？

PATCH是一个相对较新的动词(2010年3月引入的RFC),它解决了"修补"或修改一组字段的问题.在引入PATCH之前,每个人都使用PUT来更新资源.但是在引入PATCH之后,让我感到困惑的是当时使用的PUT是什么？这让我想到了第二个(也是主要的)问题:

• 什么是PUT和PATCH之间的真正区别？我读过PUT可能用于替换特定资源下的整个实体,因此应该发送完整实体(而不是像PATCH一样发送属性集).这种情况的实际用法是什么？您希望何时替换/覆盖特定资源URI下的实体以及为什么不将此类操作视为更新/修补实体？我在PUT中看到的唯一实际用例是在集合上发布PUT,即/users替换整个集合.在引入PATCH之后,在特定实体上发布PUT是没有意义的.我错了吗？

上下文

我有一个REST API,其中多个客户端(应用程序)可以使用PUT更新资源的状态.例如,此资源是您可以转动的灯ON或OFF.

当系统检测到发生电力故障时,该资源也会自动更新,导致灯处于BROKEN state. I want to made the distinction between BROKEN状态.我想区分OFF和BROKEN,一盏灯ON不能转PUT!

问题

我用PUT http://address:port/my_lamp { "state": "ON"} 方法来做这件事,比如说PUT

但我不确定我是否尊重ON方法的幂等属性.事实上,我有3个案例:

• 灯是ON.上面的代码导致了ON状态.
• 灯是ON.上面的代码导致了BROKEN状态....很酷!此时,幂等性仍然有保证:-)!
• 灯是503 Service Unavailable.上面的代码会导致错误,例如PUT

题

我不确定正确理解幂等性的概念.相信我,我读了很多关于它的事情,但仍然有点困惑.

在我的理解中,多个BROKEN总是导致资源的相同状态:在我的情况下不能保证由于PUT

但我也可以用另一种方式来理解它:多重ON总是导致相同的副作用:保证,我的请求要么产生转动BROKEN,要么没有(对于这种ON情况,它已经存在).

编辑:

请参阅此处:REST DELETE真的是幂等的吗？

哪一个是正确的？根据理解,我的REST API确保了幂等性能......

EDIT2: