我已经阅读了很多关于 PUT 和 POST 之间区别的答案。 提供的答案是 PUT 在几乎所有答案中都是幂等的。
使用 Put 时，提供一个 Id 并提供完整的实体，
我的疑问是，如果我们使用带有 id 作为输入的 post 方法与实体一起使用会有什么不同。在任何一种情况下，都必须进行数据库查询以检查数据是否存在。
那么为什么有两种不同的方法呢？如果它们的运作方式，两者之间有什么区别吗？ PUT 在技术上比 POST 提供了哪些额外的功能或特性，而不仅仅是口头上的差异。
【问题讨论】：
POST 和 PUT 方法的根本区别在于 通过所附表示的不同意图突出显示。 POST 请求中的目标资源旨在处理 根据资源自身的语义封闭表示， 而 PUT 请求中的封闭表示定义为 替换目标资源的状态。因此，PUT 的意图 是幂等的并且对中间人可见，即使确切的 效果只有源服务器知道。
https://www.rfc-editor.org/rfc/rfc7231#section-4.3.4
一个请求方法被认为是“幂等的”，如果预期的效果是 使用该方法的多个相同请求的服务器是 与单个此类请求的效果相同。请求方法 本规范定义的 PUT、DELETE 和安全请求方法 是幂等的。
就像安全的定义一样，幂等属性只适用于 用户的要求；服务器可以免费记录每个 单独请求，保留修订控制历史，或实施 每个幂等请求的其他非幂等副作用。
区分幂等方法是因为请求可以是 如果在通信失败之前发生自动重复 客户端能够读取服务器的响应。例如，如果一个 客户端发送 PUT 请求并关闭底层连接 在收到任何响应之前，客户端可以建立一个新的 连接并重试幂等请求。它知道重复 该请求将具有相同的预期效果，即使原来的 请求成功，但响应可能不同。
【讨论】：
那么为什么有两种不同的方法呢？如果它们的运作方式，两者之间有什么区别吗？
不一定。但它们的含义（语义）存在巨大差异。
Idempotent是一个重要的语义区别；在不可靠的网络上，消息会丢失。此外，无法确定丢失的消息是请求还是响应。
幂等语义允许我们做的是安排客户端在等待响应超时时重新发送请求。
此外，由于幂等承诺是 HTTP 标准本身的一部分，通用 组件可以安全地自行决定重新发送请求，而无需了解有关请求的域特定上下文的任何信息。
PUT 本身也有一些有趣的含义：
源服务器不得在对 PUT 的成功响应中发送验证器标头字段（第 7.2 节），例如 ETag 或 Last-Modified 字段，除非请求的表示数据在未对正文应用任何转换的情况下保存（即，资源的新表示数据与 PUT 请求中收到的表示数据相同）并且验证器字段值反映了新表示。这个要求允许用户代理知道它在内存中的表示体何时作为 PUT 的结果保持最新，因此不需要从源服务器再次检索，并且在响应中接收到新的验证器可用于未来的条件请求，以防止意外覆盖（第 5.2 节）。
在您的服务器实现中，您可以使用与执行 PUT 完全相同的逻辑来实现 POST；但是如果没有该方法所承诺的语义，通用客户端就无法利用。
【讨论】：