38 
 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 开发中，我使用过其他技术，我只使用过GETandPOST方法，但RESTful在 Rails 中使用路由时，默认情况下PUTandDELETE方法用于updateanddestroy操作。PUT使用and有什么好处或需要DELETE？我认为这些方法只是另一种方法POST——但为什么不坚持下去POST呢？

4

4 回答 4

70

优点主要是语义上的，并且还可以在一定程度上简化 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。）

于 2009-05-24T15:38:57.660 回答
11

这是HTTP 1.1 规范的“方法”部分；它定义了很多方法，它们都有不同的好处和权衡。POST是最灵活的，但权衡很多：它不可缓存（因此互联网的其余部分无法帮助您扩展），它不安全或幂等，因此客户端不能只是重新发送它会出错，并且不再清楚您要完成什么（因为它非常灵活）。我敢肯定还有其他人，但这应该足够了。鉴于所有这些，如果 HTTP 规范定义了一个方法，它完全按照您的请求执行，那么就没有理由发送 aPOST代替。

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

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

于 2009-05-25T21:38:00.073 回答
10

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

我将重点介绍W3 的 RFC 2616中的一些重要部分

我要开始，PUT因为在我看来，它周围最混乱。

  • PUT is used for both create/update PUT updates by completely replacing the resource on the server with the resource sent in the request

例如

你打电话给我的 api

PUT        /api/person
{
     Name: John,
     email: jdoe@hra.com
}

我的服务器有这个资源存在于服务器上

{
     Name: Jane,
     email: jdoe@hra.com
}

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

{
     Name: John,
     email: jdoe@hra.com
}

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

PUT        /api/person
{
     email: jdoe@hra.com
}

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

{
     Name: Jane,
     email: jdoe@hra.com
}

和

{
     email: jdoe@hra.com
}

名称将消失。部分更新是用于PATCH但我POST无论如何都使用它。

  • One of the main reasons why we create/update with put is because it is idempotent.

这只是一个花哨的术语，它的基本定义是多个相同的请求对于单个请求是相同的。

例子

假设我PUT有一个文件，api/file如果源服务器找不到该文件，它将创建一个。如果它确实找到了一个文件，它将用我发送的文件完全替换旧文件。这确保了一个文件被创建和更新。如果不存在文件并且您调用PUT了 5 次，则第一次创建文件，然后其他 4 次将文件替换为您发送的文件。如果您调用POST5 次来创建它将创建 5 个文件。

  • You PUT to that exact URI. If you don't you have to send a 301 (Moved Permanently) to the user and allow then make a choice whether or not to redirect the request. Most times the server you PUT to usually hosts the resource and takes care of updating it

这些是何时使用 PUT 的要点

就POST目前而言

  • You can also create/update and then some...

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

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

现在我Delete为什么不POST呢？

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

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

我只是强调了一些关于何时使用通用的要点Http verbs

于 2017-11-10T17:52:36.760 回答
8

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

于 2009-05-24T15:40:20.187 回答