rest - 为什么我们需要的不仅仅是 HTTP GET、PUT、POST？

Question

使用 HTTP GET、PUT、DELETE、POST、HEAD 的实际好处是什么？为什么不关注他们的行为优势(安全性和幂等性)，忘记他们的名字，并根据我们想要的行为使用 GET、PUT 或 POST？

为什么我们不应该只使用 GET、PUT 和 POST(以及删除 HEAD、DELETE)？

Answer 1

[REST][1] 方法使用 POST、GET、PUT 和 DELETE 来实现 Web 资源的 CRUD 规则。这是一种将对象公开给 Web 上的请求的简单而整洁的方法。它是没有开销的 Web 服务。

只是为了澄清语义差异。每个操作都相当不同。关键是要有很好的 HTTP 方法，这些方法具有清晰、不同的含义。

POST 创建新对象。 URI 没有 key ；它接受定义对象的消息体。 SQL 插入。 [编辑虽然 POST 没有 key 没有技术原因，但 REST 人员强烈建议 POST 具有与 CREATE 不同的含义，它不应该有 key 。]

GET 检索现有对象。 URI 可能有一个键，取决于你是在做单例 GET 还是列表 GET。 SQL 选择

PUT 更新现有对象。 URI 有一个 key ；它接受更新对象的消息体。 SQL 更新。

DELETE 删除现有对象。 URI 有一个 key 。 SQL 删除。

您可以使用 POST 而不是 PUT 来更新记录吗？并非没有引入一些歧义。动词应该有明确的效果。此外，POST URI 没有键，而 PUT 必须有键。

当我发布时，我期望 201 已创建。如果我不明白，那就有问题了。同样，当我 PUT 时，我期望 200 OK。如果我不明白，那就有问题了。

我想您可能会坚持在 POST 执行 POST 或 PUT 时存在一些歧义。 URI 必须不同；相关的消息也可能不同。通常，REST 人员从 SQL 中获得启发，其中 INSERT 和 UPDATE 是不同的动词。

您可以假设如果记录不存在则 UPDATE 应该插入，或者如果记录存在则更新。但是，如果 UPDATE 意味着 UPDATE 并且更新失败意味着出现问题，则更简单。对 INSERT 的 secret 回退使操作变得模棱两可。

如果您没有构建 RESTful 接口(interface)，那么通常只使用 GET 和 POST 进行检索和创建/更新。当一个人在表单上单击提交时，通常存在 URI 差异或消息内容差异来区分 POST 和 PUT。但是，它不是很干净，因为您的代码必须确定您是在 POST=create 案例还是 POST=update 案例中。