我试图在静态API的背景下理解幂等方法的概念，但我无法真正掌握它。 为什么PUT时POST方法不全能？ 我很困惑，因为在我的PUT API的用例中，我使用的是JPA的merge方法，如果不存在，它将在DB中创建一个新实体。 所以我的PUT API在某些情况下就像POST API一样，这是否意味着PUT现在变得无幂了？ 我想我什至不了解该主题的基础知识。
您是正确的，PUT和POST具有类似的效果，因为它们都可以创建资源。 但是它们有时也会表现不同，而正是在这种差别中，一个是幂等的，而另一个则不是。
如果请求方法一次接收的效果与连续两次，三次或n次接收的效果相同，则认为该方法是幂等的 。
考虑了Facebook 等 。 就像是幂等的； 如果我告诉Facebook我喜欢某件商品一次，两次或三次，那么所有这些都应具有相同的效果：用户对该商品的单次赞。
现在假设我向Facebook发送一个like ，但是响应在我的浏览器中超时。 我不知道Facebook是否得到我的喜欢。 我可以重新发送喜欢的东西吗？ 答案是肯定的！ 即使他们得到了我的第一个喜欢，对我来说第二或第三次发送也没有害处。
另一方面，考虑Facebook 评论 。 评论不是幂等的。 如果我对一个项目发送一次相同的评论，那么结果就是对该项目的一个评论。 如果我发送相同的评论三次，则结果是该项目有三个评论。 如果我向帖子发送评论，但浏览器超时，我可以重新发送评论吗？ 答案是否定的：在尝试再次发送之前，我应该刷新页面以查看是否添加了我的评论。
这就是将方法指定为幂等/非幂等方法的要点：如果客户端在幂等方法上遇到响应超时，它知道再次发送该请求是安全的； 如果客户端在非幂等方法上遇到响应超时，则不知道再次发送该请求是否安全。
考虑到这一点，让我们看一下PUT和POST。
POST用于将资源添加到集合中。 通常，您会将资源发布到诸如“ / api / students /”之类的端点。 那创造了一个新学生。 如果您一次将学生吉米（Jimmy）发布到'/ api / students /'，那么您将获得一个新的吉米（Jimmy）。 但是，如果您将学生吉米三次发送到“ / api / students /”，那么您将获得三个新的吉米！ 那不是幂等。
PUT用于在已知uri处创建或更新资源。 因此，假设您的个别学生有uri'/ api / students / 1'，'/ api / students / 2'等。如果您将Jimmy放入'/ api / students / 43'，那么结果是Jimmy现在位于'/ api / students / 43'; 如果已经有一个学生43，则替换该学生；如果没有，则创建一个学生。 如果再次将Jimmy放到'/ api / students / 43'，则效果仍然是Jimmy位于'/ api / students / 43'。 您可以将Jimmy置于'/ api / students / 43'n次，其效果与仅执行一次没有什么不同。 那是幂等的。