我试图在restful API的上下文中理解idompotent方法的概念。但是我无法真正掌握它。为什么POST方法在PUT时不是无用的？ 我很困惑，因为在我的PUT API的用例中我使用JPA的合并方法，如果不存在，则在DB中创建一个新实体。因此，在某些情况下，我的PUT API的行为类似于POST API。这是否意味着PUT现在变得非成分？ 我想我甚至不了解这个主题的基础知识。
答案 0 :(得分：1)
您正确认为PUT和POST具有类似的效果，因为它们都可以创建资源。但是他们有时也表现得不同，而且差别在于一个是幂等的而另一个不是。
如果一个请求方法在连续两次，三次或n次接收时具有与一次接收相同的效果，则称其为幂等。
考虑Facebook ，如。 喜欢是幂等的;如果我告诉Facebook我喜欢一个项目一次，两次或三次，它应该都具有相同的效果：一个像我用户的那个项目。
现在假设我向Facebook发送之类的，但响应在我的浏览器中超时。我不知道Facebook是否喜欢我。我可以重新发送我的喜欢吗？答案是肯定的！即使他们第一次喜欢我，第二次或第三次发送也没什么坏处。
另一方面，考虑Facebook 评论。评论不是幂等的。如果我对项目发送一次相同的评论，则结果是对该项目的一个评论。如果我发送相同的评论三次，那么结果是对该项目的三条评论。如果我向帖子发送评论并且我的浏览器超时，我可以重新发送评论吗？答案是否定的：在尝试再次发送之前，我应该刷新页面以查看我的评论是否已添加。
将方法指定为幂等/非幂等的主要观点是：如果客户端在幂等方法上遇到响应超时，则它知道再次发送该请求是安全的;如果客户端在非幂等方法上遇到响应超时，则它不知道再次发送该请求是否安全。
考虑到这一点，让我们看看PUT和POST。
POST用于向集合添加资源。通常，您可以将资源POST到端点，例如＆＃39; / api / students /＆＃39;。 创建新学生。如果你把学生吉米一次性地发给＆＃39; / api / students /＆＃39;然后你有一个新的吉米。但是，如果你将学生吉米三次发布到＆＃39; / api / students /＆＃39;，那么你有三个新的吉米！这不是幂等性的。
PUT用于在已知的uri 处创建或更新资源。因此，假设您的个别学生有uris＆＃39; / api / students / 1＆＃39; /＃39; / api / students / 2＆＃39;等等。如果你把Jimmy推到＆＃39; / api /学生/ 43＆＃39;然后结果是吉米现在在＆＃39; / api / students / 43＆＃39 ;;如果已经有一个学生43那么该学生被替换，如果没有，则创建一个。如果你把吉米交给＆＃39; / api / students / 43＆＃39;再次，然后效果仍然是吉米在＆＃39; / api / students / 43＆＃39;。你可以把吉米送到＆＃39; / api / students / 43＆＃39; n次，效果与仅仅做一次不同。这是幂等的。