java - 为什么 HTTP 方法 PUT 应该是幂等的而不是实现 RestFul 服务中的 POST？

Internet 上有许多可用资源，其中讨论了 PUT 与 POST。但是我不明白这将如何影响在 RestFul 服务下完成的 Java 实现或后端实现？我查看的链接如下:

例如，假设地址有一个 RestFul 网络服务。所以 POST/addresses 将完成更新地址的工作，而 PUT/addresses/1 将完成创建地址的工作。现在 HTTP 方法 PUT 和 POST 如何控制 weservice 代码在幕后做什么？

PUT /addresses/1

可能最终会在数据库中创建同一地址的多个条目。

所以我的问题是，为什么幂等行为与 HTTP 方法相关联？

您将如何通过使用特定的 HTTP 方法来控制幂等行为？还是只是建议的指南或标准做法？

我不是在寻找什么是幂等行为的解释，而是什么让我们如此标记这些 HTTP 方法？

最佳答案

这是特定于 HTTP 的。正如您链接的 RFC 所述 https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html (请参阅此答案底部的最新 RFC 链接)。它没有被描述为 REST 的一部分:https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

现在你写了，

I am not looking for an explanation of what is idempotent behavior but what make us tag these HTTP methods so?

幂等操作总是有相同的结果(我知道你知道)，但结果与 HTTP 响应不同。从 HTTP 的角度来看应该很明显，使用任何方法的多个请求甚至所有相同的参数都可以有不同的响应(即时间戳)。所以它们实际上可能不同。

不应该改变的是操作的结果。所以多次调用 PUT/addresses/1 不应该创建多个地址。

如您所见，它被称为 PUT 而不是 CREATE 是有原因的。如果资源不存在，它可能会创建资源。如果它存在，那么它可能会用新版本(更新)覆盖它，如果它完全相同应该在服务器上不做任何事情并产生相同的答案，就好像它是相同的请求(因为它可能是重复的相同请求，因为之前的请求被中断，客户端没有收到响应)。

与 SQL PUT 相比，它更像是 INSERT OR UPDATE，而不仅仅是 INSERT 或 UPDATE。

So my question is, why the idempotent behavior is linked to the HTTP method?

它与 HTTP 方法相关联，因此某些服务(代理)知道在请求失败的情况下它们可以安全地尝试(不是在安全 HTTP 方法方面而是在幂等性方面)重复它们。

How will you control the idempotent behavior by using specif HTTP methods?

我不确定你在问什么。但是:

这基本上意味着代理、缓存、网络爬虫等可以在不更改任何内容的情况下安全地创建安全方法。幂等性可以通过软件重复，不会改变结果。

Or is it that just a guideline or standard practice suggested?

这是“标准”。也许 RFC 还不是标准，但它最终会成为一个标准，我们没有其他可以(也应该)遵循的东西。

编辑:

由于上面提到的 RFC 已经过时，这里有一些关于该主题的当前 RFC 的引用:

感谢Roman Vottner征求意见。

关于java - 为什么 HTTP 方法 PUT 应该是幂等的而不是实现 RestFul 服务中的 POST？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48925525/