这里是一个简单的描述:

POST总是用于创建资源(是否复制并不重要) PUT用于检查资源是否存在，然后更新，否则创建新的资源 PATCH总是用于更新资源

这里是一个简单的描述:

POST总是用于创建资源(是否复制并不重要) PUT用于检查资源是否存在，然后更新，否则创建新的资源 PATCH总是用于更新资源

请求类型

create - POST read - GET create或update - PUT delete -删除 update - PATCH

GET/PUT是等幂的 PATCH有时是等幂的

什么是幂等的 这意味着如果我们多次触发查询，它不应该影响查询的结果。(相同的输出。假设一头牛怀孕了，如果我们再次繁殖它，那么它就不能怀孕多次)

得到:

简单的会。从服务器获取数据并显示给用户

{
id:1
name:parth
email:x@x.com
}

职位:

在数据库中创建新资源。这意味着它会添加新的数据。它不是等幂的。

将:-

创建新资源，否则添加到现有资源。 幂等的，因为它每次都会更新相同的资源，输出也会相同。 前女友。 -初始数据

{
id:1
name:parth
email:x@x.com
}

执行put-localhost / 1 把电子邮件:ppp@ppp.com

{
id:1
email:ppp@ppp.com
}

补丁

现在是补丁请求 PATCH有时是等幂的

id:1
name:parth
email:x@x.com
}

块名称:w

{
id:1
name:w
email:x@x.com
}

HTTP  Method
GET     yes
POST    no
PUT     yes
PATCH   no*
OPTIONS yes
HEAD    yes
DELETE  yes

资源: 幂等性——什么是幂等性?

这样想吧……

POST - create

PUT -替换

补丁-更新

GET - read

DELETE -删除

参考RFC: https://www.rfc-editor.org/rfc/rfc9110.html#name-method-definitions

POST -创建新对象 PUT -更新旧对象或创建新对象(如果不存在) 更新/修改旧对象。主要用于修改。

之前提到的RFC的解释很少，但如果你仔细阅读，你会注意到PUT和PATCH方法是在POST之后出现的，这是一种常见的创建原生HTML表单的老式方法。

因此，如果你试图支持所有的方法(如PATCH或DELETE)，可以建议使用所有方法的最合适的方法是坚持CRUD模型:

Create - PUT 阅读-获取 更新-补丁 删除-删除

旧的HTML原生方式: 阅读-获取 创建/更新/删除- POST

程序员们好运!: -)

PUT和PATCH w.r.t分别发送完整和部分数据进行替换/更新之间的差异非常符合逻辑。但是，我只提出以下几点

有时POST被认为是用于更新w.r.t PUT用于创建 HTTP是否要求/检查在PATCH中发送完整数据还是部分数据?否则PATCH可能与PUT/POST中的update完全相同