为什么使用 HTTP PUT 和 DELETE 方法而不是 POST？

Question

 new_story GET     /story/new(.:format)  {:action=>"new", :controller=>"stories"}
edit_story GET     /story/edit(.:format) {:action=>"edit", :controller=>"stories"}
     story GET     /story(.:format)      {:action=>"show", :controller=>"stories"}
           PUT     /story(.:format)      {:action=>"update", :controller=>"stories"}
           DELETE  /story(.:format)      {:action=>"destroy", :controller=>"stories"}
           POST    /story(.:format)      {:action=>"create", :controller=>"stories"}

在 Web 开发中，我使用过其他技术，我只使用过 GET 和 POST 方法，但在 Rails 中使用 RESTful 路由，默认情况下PUT 和 DELETE 方法用于 update 和 destroy 操作。 使用 PUT 和 DELETE 的优点或需求是什么？ 我认为这些方法只是执行 POST 的另一种方式 - 但为什么不坚持使用 POST 呢？

Answer 1

优点主要是语义上的，并且还可以在一定程度上简化 URL。 不同的 HTTP 方法映射到不同的操作：

POST   => create a new object
DELETE => delete an object
PUT    => modify an object
GET    => view an object

然后，理论上，您可以使用相同 URL，但使用不同的方法与之交互； 用于访问资源的方法定义了实际的操作类型。

但实际上，大多数浏览器仅支持 HTTP GET 和 POST。 Rails 在 HTML 表单中使用了一些“欺骗”，就像发送了 PUT 或 DELETE 请求一样，尽管 Rails 仍然对这些方法使用 GET 或 POST。 （这解释了为什么您可能没有在其他平台上使用过 DELETE 或 PUT。）

Answer 2

我只是想在已接受的答案中添加一些内容，因为他对 http 动词的定义不正确。 它们都有一个“应该”遵循的规范，您可以根据规范使用多个 http 动词 创建/更新/删除。

我将重点介绍 W3 的 RFC 2616

我将从 PUT 开始，因为在我看来，它是最令人困惑的。

• PUT 用于创建/更新 PUT 更新，方法是用请求中发送的资源完全替换服务器上的资源

例如，

您对我的 api 进行此调用，

PUT        /api/person
{
     Name: John,
     email: [email protected]
}

我的服务器在服务器上拥有此资源

{
     Name: Jane,
     email: [email protected]
}

现在，我现有的资源已完全被您发送过来的资源所取代，这就是我服务器上的资源。

{
     Name: John,
     email: [email protected]
}

因此，如果您PUT并且仅在正文中发送电子邮件，

PUT        /api/person
{
     email: [email protected]
}

我的服务器将完全替换实体

{
     Name: Jane,
     email: [email protected]
}

，并且

{
     email: [email protected]
}

名称将消失。 部分更新是针对 PATCH 的，但我还是使用 POST 来进行更新。

• 我们使用 put 创建/更新的主要原因之一是因为它是幂等的。

这只是一个奇特的术语，它的基本定义是多个相同的请求对于单个请求来说是相同的。

示例

假设我将一个文件PUT 到api/file，如果源服务器找不到该文件，它将创建一个文件。 如果它确实找到了一个文件，它将用我发送过来的文件完全替换旧文件。 这可以确保创建和更新一个文件。如果不存在文件并且您调用 PUT 5 次，则第一次创建文件，然后另外 4 次将替换包含您发送过来的内容的文件。 如果您调用 POST 5 次来创建，它将创建 5 个文件。

• 您 PUT 到该确切的 URI。 如果不这样做，则必须向用户发送 301（永久移动）并允许，然后选择是否重定向请求。 大多数时候，您 PUT 到的服务器通常托管资源并负责更新它

这些是何时使用 PUT 的要点

就 POST 而言

• 您还可以创建/更新，然后一些...

正如我上面提到的，有一些关键的区别。

• 帖子比较一般。 以什么方式？ 其他一些示例包括通往其他协议的网关，它可以获取响应并将其发送到远处的某个数据处理程序，或者它可以扩展某种功能。
• Post 没有“到确切的 URI 或通知”的限制，例如 POST 可以将资源附加到现有集合并决定其存储位置。

现在Delete怎么样？为什么我不直接POST呢？

当您DELETE时，服务器不应该响应成功，除非您当时删除资源或将其移动到无法访问的位置响应已发送。

为什么这很重要？ 如果您调用 DELETE 但资源在删除之前必须经过“APPROVAL”怎么办？ 如果删除可以被拒绝，您就无法发送成功的错误代码，并且如果您确实遵循了基本规范，那么调用者就会感到困惑。 这只是一个例子，我相信您还可以想到许多其他例子。

我只是强调了有关何时使用常见 Http 动词 的一些要点

Answer 3

这是 HTTP 1.1 规范的 “方法”部分； 它定义了很多方法，并且它们都有不同的优点和权衡。 POST 是最灵活的，但需要权衡很多：它不可缓存（因此互联网的其余部分无法帮助您扩展），它不安全或幂等，因此客户端无法只是重新发送它会出现错误，并且不再清楚您要完成的任务（因为它非常灵活）。 我确信还有其他的，但这应该足够了。 鉴于此，如果 HTTP 规范定义的方法完全符合您希望请求执行的操作，则没有理由发送 POST。

POST 如此常见的原因是，至少从历史上看，网络浏览器仅支持 GET 和 POST。 由于 GET 被定义为安全且幂等的（即使许多应用程序不遵守这一点），因此修改数据的唯一安全方法是发送 发布。 随着 AJAX 和非浏览器客户端的兴起，情况已不再如此。

顺便说一句，@mipadi 给出的映射是标准映射，但它不是唯一有效的映射。 例如，Amazon S3 使用 PUT 创建资源。 使用POST 的唯一原因是客户端没有足够的知识来创建资源，例如，您使用关系数据库支持资源并使用人工代理键​​。

Answer 4

这有点像问为什么要“删除”文件，而您可以将其内容设置为零字节，并且文件系统只会将其视为删除。 HTTP 永远支持除 GET/POST 之外的动词，但 SOAP 的演变方式有点扭曲了这些动词的原始含义。 REST 是一种更简单、回归基础的方法，它按预期使用动词，而不是在有效负载内发明一些新的动词概念。