命令作为POST的预期效果而不是PUT的副作用

Question

POST法的预期效果(语义)是特定于资源的，例如执行带有参数的命令：

POST /command HTTP/1.1

{"parameter-1": "argument-1", "parameter-2": "argument-2"}

放置法的预期效果(语义)是用封闭的表示形式定义的状态来创建或替换目标资源的状态，但是PUT方法的副作用是特定于资源的，例如执行带有参数的命令：

PUT /command HTTP/1.1

{"parameter-1": "argument-1", "parameter-2": "argument-2"}

请参阅RFC 7231，第4.3.4节：

应用于目标资源的PUT请求可能对其他资源产生副作用。例如，一篇文章可能有一个URI，用于标识“当前版本”(一个资源)，它与标识每个特定版本的URI是分开的(不同的资源一度与当前版本资源共享相同的状态)。因此，对“当前版本”URI的成功PUT请求除了更改目标资源的状态之外，还可能创建一个新的版本资源，还可能导致在相关资源之间添加链接。

那么，执行命令作为POST的预期效果与PUT的副作用有什么好处呢？

Answer 1

正如你在问题中所说的，区别在于意图。PUT的副作用对调用者来说并不重要，他们也不对此负责。POST的预期效果是调用者正在做的事情，也是他们的责任。如果你同时控制客户端和服务器，你可以自由地做你喜欢做的事情，但我看不出有什么好的理由打破惯例。

但是，如果您的预期效果(而不是副作用)是幂等的，则可以使用PUT (节7231第4.2.2节)。

如果多个相同请求对服务器的预期效果与单个请求的效果相同，则请求方法被认为是“幂等的”。

Answer 2

如果我放置一个资源表示，那么期望相同资源的GET返回一个等价的表示。例如，如果我在PUT /command中使用body print("hello world")，那么以后的GET /command可能会返回命令，或者执行命令的结果。

给定表示的成功放置将意味着后续的GET在同一目标资源上将导致在200 (OK)响应中发送一个等效的表示。(RFC 7231)

对于POST，不期望在该URL上创建或更新资源。非常常见的情况是，发送到URL的帖子会创建不同的资源( 303参见其他的或201创建的响应可能重定向到该资源)。但是，POST可能不会触及任何资源，而被调用纯粹是因为它的副作用。

例如，让我们考虑一个基于HTTP的版本控制系统。每个版本都由一个像/version/d1623a5这样的URL来标识。还有像/version/latest这样的浮动标签。不同的设计将如何创造一个新版本？

• 在基于PUT的设计中，我可以通过PUTting直接创建一个版本资源--它的URL是一个新的表示：>PUT / version /c0af447 >>作为副作用创建的新内容< 201，这可能会更新/version/latest指向的资源。这样的空头也是幂等的。如果失败了，我可以安全地再试一次。如果版本资源已经存在，我可能会得到204个No内容响应。或者，我可以将最新版本：> PUT /version/ create >>新内容<204No content作为一个副作用，这可能会创建资源/version/c0af447。
• 在基于POST的设计中，我不会直接发布到版本资源，而是发送到一个创建新版本的URL：> POST / version /new >>新内容< 303 --参见其他< Location: / version /c0af447 --这不能安全地重新尝试:重复的POST请求通常会创建另一个版本。在实践中，使用POST仍然非常流行，因为它是相当通用的，而且比PUT更不受限制。这是一个合理的默认更改服务器上的“某物”。