问PATCH和PUT请求的主要区别是什么？

EN

HTTP动词可能是HTTP协议中最神秘的东西之一。它们是存在的，而且数量很多，但它们为什么存在呢？

Rails似乎想要支持许多动词，并添加一些web浏览器本身不支持的动词。

下面是http动词的详尽列表：http://annevankesteren.nl/2007/10/http-methods

这里有来自官方RFC的HTTP补丁：https://datatracker.ietf.org/doc/rfc5789/?include_text=1

补丁(

)方法请求将请求实体中描述的一组改变应用于由请求URI标识的资源。改变集以被称为由媒体类型标识的“补丁文档”的格式来表示。如果Request-URI不指向现有资源，则服务器可以根据补丁文档类型(是否可以逻辑地修改空资源)和权限等来创建新资源。

PUT和PATCH请求之间的差异反映在服务器处理封闭实体以修改由Request-URI标识的资源的方式上。在PUT请求中，封装的实体被认为是源站上存储的资源的修改版本，客户端请求替换存储的版本。然而，使用PATCH，时，所包含的实体包含一组指令，描述如何修改当前驻留在源服务器上的资源以产生新版本。补丁方法影响由-URI标识的资源，并且它还可能对其他资源具有副作用；即，可以通过应用补丁来创建新资源或修改现有资源。

据我所知，补丁动词并没有像在rails应用程序中那样使用……据我所知，RFC补丁动词应该用来发送补丁指令，就像你在两个文件之间做比较一样。不是再次发送整个实体，而是发送一个可能比重新发送整个实体小得多的补丁。

想象一下，你想要编辑一个大文件。您可以编辑3条线。您只需发送diff，而不是将文件发回。从好的方面来说，发送补丁请求可以用来异步合并文件。版本控制系统可能会使用补丁动词远程更新代码。

另一种可能的用例与NoSQL数据库有些关系，可以存储文档。假设我们使用JSON结构在服务器和客户端之间来回发送数据。如果我们想删除一个字段，我们可以使用类似于mongodb for $unset中的语法。实际上，mongodb中用来更新文档的方法可能被用来处理json补丁。

以这个例子为例：

db.products.update(
   { sku: "unknown" },
   { $unset: { quantity: "", instock: "" } }
)

我们可以有这样的东西：

PATCH /products?sku=unknown
{ "$unset": { "quantity": "", "instock": "" } }

最后但并非最不重要的一点是，人们可以对HTTP动词说任何他们想说的话。只有一个真相，而真相就在RFC中。

我花了几个小时在谷歌上找到了答案here

PUT => 如果用户可以更新全部或部分记录，则使用PUT(用户控制更新的内容)

PUT /users/123/email
new.email@example.org

PATCH => 如果用户只能更新部分记录，比如一个电子邮件地址(应用程序控制可以更新的内容)，请使用PATCH。

PATCH /users/123
[description of changes]

为什么选择Patch

PUT方法需要更多带宽或处理全部资源，而不是部分。因此引入了PATCH来减少带宽。

关于补丁的说明

PATCH是一种既不安全也不幂等的方法，并且允许对其他资源进行完全和部分更新以及副作用。

PATCH是一种方法，其中封装的实体包含一组指令，描述如何修改当前驻留在源站上的资源以生成新版本。

PATCH /users/123
[
  { "op": "replace", "path": "/email", "value": "new.email@example.org" }
]

Here有关put和patch的详细信息

put:

如果我想更新我的first名称，那么我会发送一个put请求：

{ "first": "Nazmul", "last": "hasan" } 

但使用put请求有一个问题:当我想发送put请求时，我必须发送所有两个参数，即first和last (而我只需要更新first)，因此必须使用put请求再次发送它们。

修补程序：

另一方面，patch请求说:只需指定需要update的data，它就不会影响或更改其他数据。

因此，不需要再次发送所有值。我只需要更改first名称吗？那么，在patch请求中指定first就足够了。