Rest HTTP方法POST必然是幂等的吗？

我和REST陷入了一个理论问题

想象一个简单的产品库存API。数据库包含一组运动，这些运动引用了

产品

、

数量

和

状态

我有一个先决条件：我不希望API用户操纵状态。状态值可以是

保留

或

确认

首先，我想创建一个产品预订。下面是相应的URL路径和HTTP方法来表示：

[POST]/products/{product id}/reservations

这将创建状态为保留的移动，并返回所创建移动的id

现在，我想确认这个预订：

[POST]/reservations/{movement id}/confirmations

在语义上，我似乎创建了一个确认的预订。事实上，我只是改变了运动的状态

所以，有两个问题：

我的第二篇文章是幂等的。我无法在RFC中找到信息，但是POST可以是幂等的吗

您认为有更好的方式来表示确认吗

---

我会用PUT代替。e、 g.

PUT/reservations/{movement id}/状态“已确认”

注:

---

您的帖子是幂等的并不重要，因为您在确认预订后删除了链接（HATEOAS），所以对于同一预订，2次确认到达的几率非常低。无论如何，我认为PUT更合适。

就我个人而言，我不经常看到幂等POST实现，因为这种方法不应该这样使用。幂等HTTP方法是可以多次调用而不会产生不同结果的HTTP方法。如果您想坚持POST请求，只需确保多次调用它不会改变结果，或者只使用不同的方法，例如PUT to change STATUS，因为它经常用于修改。您说过“不应该”。在RFC术语中，这是一个有意义的词。你能给我一个资源来证实这一点吗？或者，我不认为幂等性与结果有关，而是更多地与服务器状态有关（在数据库中创建了一个新实体，…）。当谈到

POST

请求时，规范说它不是幂等的。这意味着不能保证幂等性。但是，这并不意味着您需要确保多个

POST

请求不会产生与仅发出一个请求相同的结果。因此，

POST

可能是幂等的，但与

PUT

不同，规范并不保证它<代码>放置确实是更合适的选择。谢谢你的回答。当然，我考虑过你的解决方案，但正如我在问题中所说的，我不希望API的用户定义新的状态。在您的解决方案中，状态可以是用户想要的任何东西。此外，我更喜欢API的语义使用。我没有说我使用了一些超媒体系统，但问题更多的是：POST请求是否可以是幂等的？@Gnucki您应该验证状态。POST通常不是幂等的，但如果需要，可以使用幂等的方式。至少我在HTTP标准中没有发现任何关于这方面的限制，只是如果没有新资源，就必须使用200或204而不是201。我不建议您以这种方式使用POST，如果您没有找到更好的HTTP方法，这是一个例外，而不是一个规则。好的。感谢您的建议和搜索！