GET,PUT,POST含义与区别

  • A+
所属分类:网络基础

GET操作时安全的。所谓安全是指不管进行多少次的操作,资源的状态都不会改变。比如我用GET浏览文章,不管浏览多少次,那篇文章还在那,没有变化。当然,你可以说每浏览一次文章,文章的浏览数就加一,这不也改变了资源的状态吗?这并不矛盾,因为这个改变不是GET这步操作所造成的,而是我们自己设定的服务器端逻辑造成的。

PUT,DELETE操作是幂等的。所谓幂等是指不管进行多少次操作,结果都一样。比如我用PUT修改一篇文章,然后再做同样的操作,每次操作之后的结果并没有不同,DELETE也是一样。顺便说一句,因为GET操作是安全的,所以他自然也是幂等的。

POST操作既然是不安全的,也不是幂等的,比如常见的POST重复加载问题:当我们多次发出同样的POST请求后,其结果是创建了若干的资源。

安全和幂等的异议在于:当操作没有达到预期的目标时,我们可以不停的重试,而不会对资源产生副作用,从这个意义上说,POST操作往往是有害的,但很多时候我们还是不得不使用它。

还有一点需要注意的是,创建操作可以使用POST,也可以使用PUT,区别在于POST是作用在一个结合资源之上的(/url),而PUT操作是作用在一个具体资源之上(/url/xxx),再通俗点说,如果URL可以在客户端确定,那么就使用PUT,如果在服务端确定,那么就使用POST,比如说很多资源使用数据库自增主键作为标识信息,而创建的资源的标识信息到底是什么只能由服务端提供,这个时候就必须使用POST。

关于GET POST的混淆

先说相同点,只有了解了相同点之后才能理解为什么会发生混淆

两者都能向服务器发送数据,提交的“内容”的格式相同,都是

GET和POST区别如字面,一个是GET(获取),一个是POST(发送)。

GET用来告诉服务器需要获取哪些内容(url+query),向静态页面(url)请求则直接返回文件内容给服务器,向一个动态页面请求时可以提供查询参数(query)以获得相应内容。

POST用来向服务器提交内容,主要是为了提交,而不是为了请求内容,就是说POST的初衷并不要求服务器返回内容,只是提交内容让服务器处理(主要是储存或者处理之后再储存)。

GET和POST出现混淆是因为对提交的数据处理方式的滥用造成的,数据是无辜的。

混淆之一:

将GET提交的用来查询的字段当作是存储数据存入了服务器文件或者数据库,然后就误以为GET是用来提交用于储存的数据的。

混淆之二:

编写脚本在服务器端通过处理POST提交的数据并返回内容。只要有数据,就能用来进行判断,脚本怎写是程序员的事,而不在乎数据来源的形式(POST、GET,或者是自己预设值的常量)。这点功能上确实没问题,只是背离的其初始目的而已。

由于都是要传送数据,且数据格式相同(即使数据格式不同,只要能提取出相应数据)。使用的时候难免出现张冠李戴,将get数据用来存储、将POST数据用来检索返回数据。但是二者还是有区别的(主要是根据其用途而“人为”造成的),GET的长度限制在2048字节(由浏览器和服务器限制的,这是目前IE的数据,曾经是1024字节),很大程度上限制了GET用来传递“存储数据”的数据的能力,所以还是老老实实用来做检索吧;POST则无此限制(只是HTTP协议规范没有进行大小限制,但受限于服务器的处理能力),因此对于大的数据(一般来说需要存储的数据可能会比较大,比2048字节大)的传递有天然的优势,谁让它是 nature born post 呢。

GET提交的数据是放在url里,目的是灵活的向服务其提交检索请求,可以在地址栏随时修改数据以变更需要获取的内容,比如直接修改分页的编号就跳到另外一个分页了(当然也可能是 404)。post提交的数据放在HTTP请求的正文里,目的在于提交数据并用于服务器端的存储,而不允许用户过多的更改相应数据(主要是相对于在url 修改要麻烦很多,url的修改只要点击地址栏输入字符就可以了),除非是专门跑来编辑数据的。

PS:POST和GET的安全性在传输的层面上区别不大,但是采用url提交数据的GET方式容易被人肉眼看到,或者出现在历史纪录里,还是可能被肉眼看到,都是一些本地的问题。

注1:我强调的是内容,至于http协议中的GET和POST的格式大家有兴趣就自己看看吧。
注2:GET方式主要是为了获得预期内容,即uri+query相同时所得到的内容应该是相同的。而post主要是提交内容,至于是否有必要返回页面可能只是出于用户体验,比如注册时返回你的注册id,但是如果只是返回一个“您已注册成功”的相同页面(即使你POST的数据不一样)也没什么好奇怪的。
注3:关于这个“人为”,不是那么贴切,GET和POST还是有技术层面的区别的。但是从表象上看暂且这么说吧,毕竟二者的混淆也是“人为”的。

总结:

  • GET 请求可被缓存
  • GET 请求保留在浏览器历史记录中
  • GET 请求可被收藏为书签
  • GET 请求不应在处理敏感数据时使用
  • GET 请求有长度限制
  • GET 请求只应当用于取回数据

 

  • POST 请求不会被缓存
  • POST 请求不会保留在浏览器历史记录中
  • POST 不能被收藏为书签
  • POST 请求对数据长度没有要求

 

GET
后退按钮/刷新 无害 数据会被重新提交(浏览器应该告知用户数据会被重新提交)。
书签 可收藏为书签 不可收藏为书签
缓存 能被缓存 不能缓存
编码类型 application/x-www-form-urlencoded application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史 参数保留在浏览器历史中。 参数不会保存在浏览器历史中。
对数据长度的限制 是的。当发送数据时,GET 方法向 URL 添加数据;URL 的长度是受限制的(URL 的最大长度是 2048 个字符)。 无限制。
对数据类型的限制 只允许 ASCII 字符。 没有限制。也允许二进制数据。
安全性 与 POST 相比,GET 的安全性较差,因为所发送的数据是 URL 的一部分。

在发送密码或其他敏感信息时绝不要使用 GET !

POST 比 GET 更安全,因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性 数据在 URL 中对所有人都是可见的。 数据不会显示在 URL 中。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: