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

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

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

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

只是为了澄清语义差异.每个操作都有很大的不同.关键是要有一个很好的HTTP方法,它们具有清晰,明确的含义.

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

GET检索现有对象.URI 可能有一个键,取决于您是在进行单例GET还是列出GET.SQL选择

PUT更新现有对象.URI有一个键; 它接受更新对象的消息体.SQL更新.

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

你能用POST而不是PUT更新记录吗？并非没有引入一些含糊之处.动词应具有明确的效果.此外,POST URI没有密钥,PUT必须有密钥.

当我发布POST时,我预计会创建一个201.如果我不明白,那就错了.同样,当我PUT时,我期待200 OK.如果我不明白,那就错了.

我想你可以坚持一些歧义,POST可以POST或PUT.URI必须是不同的; 相关的消息也可能不同.通常,REST人员从SQL中获取提示,其中INSERT和UPDATE是不同的动词.

如果记录不存在,您可以设置UPDATE应插入的情况,如果记录存在则更新.但是,如果UPDATE意味着UPDATE并且更新失败意味着出错,则更简单.对INSERT的秘密回落使得操作变得模糊不清.

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

POST无法保证安全性或幂等性.这是 PUT和 DELETE的一个原因- 两个PUT和DELETE都是幂等的(即1 + N个相同的请求与1个请求具有相同的最终结果).

PUT用于设置给定URI的资源状态.当您向特定URI的资源发送 POST请求时,该资源 不应被内容替换.最多应该附加到.这就是为什么POST不幂等,在附加职位的情况下,每个请求将增加的资源(例如,发布新的每一次消息的讨论论坛).

DELETE用于确保从服务器中删除给定URI的资源.除了提交删除请求的情况外,通常不应使用 POST进行删除.同样,在这种情况下,您要POST的资源的URI不应该是要删除的资源的URI.POST到的任何资源都是一种资源,它接受POSTed数据附加到自身,添加到集合或以其他方式处理.

如果您关心的只是GET请求的标头,并且您不想在实际内容上浪费带宽,则使用 HEAD.这很好.

为什么我们需要的不仅仅是POST？它允许数据双向流动,那么为什么需要GET呢？答案与您的问题基本相同.通过标准化各种方法的基本期望,其他过程可以更好地知道该做什么.

例如,干预缓存代理可以更好地做出正确的事情.

比如想想HEAD.如果代理服务器知道HEAD的含义,则它可以处理来自先前GET请求的结果,以便为HEAD请求提供正确的答案.它可以知道POST,PUT和DELETE不应该被缓存.