在rest服务中混合发布和放置更新

我知道这可能是第无数次有人开始讨论这个问题，但我找不到我的具体问题的答案

我们在内部讨论是否在rest服务中使用PUT进行更新。我们同意优先使用PUT。然而，PUT需要是幂等的。这是否意味着我们应该根据不同的更新路径的幂等性来混合POST和PUT动词

作为一个具体的例子。我们有一条更新路线，可以说是一辆“汽车”。对于此更新路由，您可以（除其他外）传递超链接。此超链接在保存时将获得一个id，并将链接到更新的汽车。但是，每次更新汽车时，生成的超链接id都会不同。这是否意味着更新不再是幂等的？即使超链接的实际目标相同

如果是这样的话，我们应该使用POST动词进行更新，而不是PUT动词。但是，我们还有许多其他的等幂更新路由。他们应该留在原地吗？我相信这会让服务的消费者非常困惑

简言之：

• 根据更新路由是否为幂等路由，混合使用PUT和POST是一个好主意吗
• 还是动词的一致性胜过幂等规则，我们应该对所有更新路由使用PUT吗
• 还是应该放弃到处使用PUT和use POST的想法，以避免完全混淆

---

使用POST创建实体，并使用PUT（或部分更新补丁）更新实体

---

如果您的实体没有稳定的唯一标识符，这表明您不能引用特定实体，您应该使用POST

通常的规则是，如果客户端知道它正在创建的资源的目标URI，

PUT

总是首选

POST

在创建新资源时很受欢迎，但这在很大程度上是因为许多API想要确定目标URI（例如，如果数据库使用自动递增id）。

我与stackoverflow以外的人进行了一些讨论。我们得出以下结论：

• 混合发布和发布更新不是一个好主意，这会让消费者感到困惑
• 一致性胜过PUT的幂等规则
• 到处使用post不是一个好主意，因为人们习惯于使用PUT进行更新

---

理想情况下，我们会修改代码（从最初问题中的示例中），以确保超链接的id不会更改。在这种情况下，将不会讨论使用PUT或POST。如果我们不能做到这一点，我们将在API自述中写一个“免责声明”，以确保让人们知道某些PUT路由不是真正的幂等的

问题是，我不是在创建资源，而是在更新它们。每个人都在谈论创造资源，这就是为什么我创造了这个问题。您能试着回答我的原始问题中的具体问题吗？我的实体有稳定的标识符，但是在保存时，正在保存的实体的子实体也会更新，并且子实体的标识符会更改。你能试着回答我最初问题中的具体问题吗？