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