为什么我们需要的不仅仅是 HTTP GET、PUT、POST? [英] Why do we need anything more than HTTP GET, PUT, POST?

问题描述

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

What is the practical benefit of using HTTP GET, PUT, DELETE, POST, HEAD? Why not focus on their behavioral benefits (safety and idempotency), forgetting their names, and use GET, PUT or POST depending on which behavior we want?

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

推荐答案

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

The [REST][1] approach uses POST, GET, PUT and DELETE to implement the CRUD rules for a web resource. It's a simple and tidy way to expose objects to requests on the web. It's web services without the overheads.

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

Just to clarify the semantic differences. Each operation is rather different. The point is to have nice HTTP methods that have clear, distinct meanings.

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

POST creates new objects. The URI has no key; it accepts a message body that defines the object. SQL Insert. [Edit While there's no technical reason for POST to have no key, the REST folks suggest strongly that for POST to have distinct meaning as CREATE, it should not have a key.]

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

GET retrieves existing objects. The URI may have a key, depends on whether you are doing singleton GET or list GET. SQL Select

PUT 更新现有对象.URI 有一个键；它接受更新对象的消息正文.SQL 更新.

PUT updates an existing object. The URI has a key; It accepts a message body that updates an object. SQL Update.

DELETE 删除现有对象.URI 有一个键.SQL 删除.

DELETE deletes an existing object. The URI has a key. SQL Delete.

你能用 POST 而不是 PUT 来更新记录吗?并非没有引入一些歧义.动词应该具有明确的效果.此外，POST URI 没有键，而 PUT 必须有键.

Can you update a record with POST instead of PUT? Not without introducing some ambiguity. Verbs should have unambiguous effects. Further, POST URI's have no key, where PUT must have a key.

当我发布时，我期望 201 CREATED.如果我不明白，那就出问题了.同样，当我 PUT 时，我期望 200 OK.如果我不明白，那就出问题了.

When I POST, I expect a 201 CREATED. If I don't get that, something's wrong. Similarly, when I PUT, I expect a 200 OK. If I don't get that, something's wrong.

我想你可以坚持在 POST 执行 POST 或 PUT 的地方有些歧义.URI 必须不同；关联的消息也可能不同.通常，REST 人员从 SQL 中获取线索，其中 INSERT 和 UPDATE 是不同的动词.

I suppose you could insist on some ambiguity where POST does either POST or PUT. The URI has to be different; also the associated message could be different. Generally, the REST folks take their cue from SQL where INSERT and UPDATE are different verbs.

您可以说明如果记录不存在则 UPDATE 应该插入，或者如果记录存在则更新.但是，如果 UPDATE 意味着 UPDATE 而更新失败意味着有问题，那就更简单了.对 INSERT 的秘密回退使操作变得模棱两可.

You could make the case that UPDATE should insert if the record doesn't exist or update if the record does exist. However, it's simpler if UPDATE means UPDATE and failure to update means something's wrong. A secret fall-back to INSERT makes the operation ambiguous.

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

If you're not building a RESTful interface, then it's typical to only use GET and POST for retrieve and create/update. It's common to have URI differences or message content differences to distinguish between POST and PUT when a person is clicking submit on a form. It, however, isn't very clean because your code has to determine if you're in the POST=create case or POST=update case.

这篇关于为什么我们需要的不仅仅是 HTTP GET、PUT、POST?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！