HTTP协议中PUT和POST使用区别

HTTP中的PUT和POST方法在资源操作上有显著差异。PUT是幂等的,意味着多次请求相同的效果,常用于更新资源;而POST不是幂等的,通常用于创建资源。误用可能导致意料之外的结果,如在非幂等服务上使用PUT可能会导致资源被重复创建。遵循HTTP协议规范对于确保服务正确性和避免意外状态变化至关重要。

1: get 获取,post 推送,get 是从服务器获取,post是向服务器推送数据

2: get 的信息都在url 里面,post 是在content-values 里面

3: get 因为信息在url 里面很不安全,post 相对安全(其实也不安全,最好用https)

 

 

 

参考:

http://blog.youkuaiyun.com/mad1989/article/details/7918267

有的观点认为,应该用POST来创建一个资源,用PUT来更新一个资源;有的观点认为,应该用PUT来创建一个资源,用POST来更新一个资源;还有的观点认为可以用PUT和POST中任何一个来做创建或者更新一个资源。这些观点都只看到了风格,争论起来也只是争论哪种风格更好,其实,用PUT还是POST,不是看这是创建还是更新资源的动作,这不是风格的问题,而是语义的问题。



在HTTP中,PUT被定义为idempotent的方法,POST则不是,这是一个很重要的区别。



   “Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.”



上面的话就是说,如果一个方法重复执行多次,产生的效果是一样的,那就是idempotent的。



      举一个简单的例子,假如有一个博客系统提供一个Web API,模式是这样http://superblogging/blogs/post/{blog-name},很简单,将{blog-name}替换为我们的blog名字,往这个URI发送一个HTTP PUT或者POST请求,HTTP的body部分就是博文,这是一个很简单的REST API例子。我们应该用PUT方法还是POST方法?取决于这个REST服务的行为是否是idempotent的,假如我们发送两个http://superblogging/blogs/post/Sample请求,服务器端是什么样的行为?如果产生了两个博客帖子,那就说明这个服务不是idempotent的,因为多次使用产生了副作用了嘛;如果后一个请求把第一个请求覆盖掉了,那这个服务就是idempotent的。前一种情况,应该使用POST方法,后一种情况,应该使用PUT方法。


 

      也许你会觉得这个两个方法的差别没什么大不了的,用错了也不会有什么问题,但是你的服务一放到internet上,如果不遵从HTTP协议的规范,就可能给自己带来麻烦。比如,没准Google Crawler也会访问你的服务,如果让一个不是indempotent的服务可以用indempotent的方法访问,那么你服务器的状态可能就会被Crawler修改,这是不应该发生的。

国外文章摘录,具体忘记名称作者和url了~

 

HTTP 协议中,`POST` `PUT` 都是用于向服务器发送数据的请求方法,但它们的设计目的语义有明显区别。 --- ### 一、基本定义 #### ✅ POST - **用途**:用于**创建**新资源。 - **语义**:向指定资源(通常是资源集合)提交数据,请求服务器根据提交内容创建一个**新的子资源**。 - **幂等性**:**不幂等**。多次相同的 POST 请求通常会创建多个资源。 - **安全性**:**不安全**,因为会改变服务器状态。 - **常见使用场景**: - 用户注册 - 提交评论或表单 - 创建订单等 #### ✅ PUT - **用途**:用于**更新**已有资源。 - **语义**:将客户端提供的完整资源**替换**目标资源的内容。如果资源不存在,某些服务端也可能用它来创建资源。 - **幂等性**:**幂等**。多次相同的 PUT 请求对资源的影响是一样的。 - **安全性**:**不安全**,也会改变服务器状态。 - **常见使用场景**: - 更新用户信息 - 替换文件内容 - 同步完整资源状态 --- ### 二、对比总结表 | 特性 | POST | PUT | |------------------|-------------------------------|---------------------------------| | 用途 | 创建资源 | 更新资源 | | 是否幂等 | 否 | 是 | | 是否安全 | 否 | 否 | | 对资源 ID 的控制 | 由服务器生成 | 由客户端指定 | | 请求体含义 | 新资源的部分或全部信息 | 要替换/设置的完整资源 | | 对已有资源影响 | 可能新增一个条目 | 替换整个现有资源 | --- ### 三、示例说明 #### ✅ POST 示例(创建资源) ``` POST /users HTTP/1.1 Content-Type: application/json { "name": "张三", "email": "zhangsan@example.com" } ``` 服务器响应: ``` HTTP/1.1 201 Created Location: /users/123 ``` #### ✅ PUT 示例(更新资源) ``` PUT /users/123 HTTP/1.1 Content-Type: application/json { "name": "李四", "email": "lisi@example.com" } ``` 服务器将 `/users/123` 的内容完全替换为请求体中的内容。 --- ### 四、选择建议 - 使用 **POST** 当你希望服务器根据你的数据**新建一个资源**,且你不关心它的唯一标识。 - 使用 **PUT** 当你已经知道资源的 URI,并希望**更新或替换该资源**。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值