看了网上很多的关于Http请求方式的文章,众说纷纭,于是决定自己花点时间总结一番,与大家分享,如有不妥之处还望海涵。
Http的几种请求方式:
HTTP是一个客户端(用户)和服务端(网站)之间请求和应答的标准。标准的存在意义就是为了统一概念,只是HTTP协议的一种规范,也可以说是一种约定,语义化的定义可以使大家规范的获取Http 请示方式后进行相应的资源处理。
GET
get请求是用来获取数据的,只是用来查询数据,不对服务器的数据做任何的修改,新增,删除等操作。
在这里我们认为get请求是安全的,以及幂等的。安全就是指不影响服务器的数据,幂等是指同一个请求发送多次返回的结果应该相同。
特点:
get请求会把请求的参数附加在URL后面,这样会产生安全问题(注入攻击),如果是系统的登陆接口采用的get请求,需要对请求的参数做一个加密。
get请求其实本身HTTP协议并没有限制它的URL大小,但是不同的浏览器对其有不同的大小长度限制
POST
向指定资源提交数据,请求服务器进行处理(例如提交表单或者上传文件)。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源,或二者皆有。
PUT
client对一个URI发送一个Entity,服务器在这个URI下如果已经又了一个Entity,那么此刻服务器应该替换成client重新提交的,也由此保证了PUT的幂等性。如果服务器之前没有Entity ,那么服务器就应该将client提交的放在这个URI上。总结一个字:PUT。对的,PUT的方法就是其字面表意,将client的资源放在请求URI上。对于服务器到底是创建还是更新,由服务器返回的HTTP Code来区别。
注:通过上面可以知道,如果用PUT来达到更改资源,需要client提交资源全部信息,如果只有部分信息,不应该使用PUT(因为服务器使用client提交的对象整体替换服务器的资源)。
DELETE
请求服务器删除Request-URI所标识的资源。
PATCH
PATCH 用于资源的部分内容的更新,例如更新某一个字段。具体比如说只更新用户信息的电话号码字段
而 PUT 用于更新某个资源较完整的内容,比如说用户要重填完整表单更新所有信息,后台处理更新时可能只是保留内部记录 ID 不变。
HEAD
HEAD方法跟GET方法相同,只不过服务器响应时不会返回消息体。一个HEAD请求的响应中,HTTP头中包含的元信息应该和一个GET请求的响应消息相同。这种方法可以用来获取请求中隐含的元信息,而不用传输实体本身。也经常用来测试超链接的有效性、可用性和最近的修改。
简而言之:
HEAD请求常常被忽略,但是能提供很多有用的信息,特别是在有限的速度和带宽下。主要有以下特点:
1、只请求资源的首部;
2、检查超链接的有效性;
3、检查网页是否被修改;
TRACE
回显服务器收到的请求,主要用于测试或诊断。
OPTIONS
这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*'来代替资源名称,向Web服务器发送OPTIONS请求,可以测试服务器功能是否正常运作
CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接(经由非加密的HTTP代理服务器)。
方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候,服务器应当返回状态码405(Method Not Allowed),当服务器不认识或者不支持对应的请求方法的时候,应当返回状态码501(Not Implemented)。
GET 和 POST 请求的优缺点、区别以及误区:
Get和Post在面试中一般都会问到,一般的区别:
(1)post更安全(不会作为url的一部分,不会被缓存、保存在服务器日志、以及浏览器浏览记录中)
(2)post发送的数据更大(get有url长度限制)
(3)post能发送更多的数据类型(get只能发送ASCII字符)
(4)post比get慢
(5)post用于修改和写入数据,get一般用于搜索排序和筛选之类的操作(淘宝,支付宝的搜索查询都是get提交),目的是资源的获取,读取数据
虽然在开发中经常用get或者post请求,但是由于我们资历经验的欠缺,或许就重来没有深究过什么场合用get请求,什么场合用post请求,我相信不止我一个人当看到第4,5条的时候,就会明白为什么面试官对我们的回答不满意,也明白了自己对get或post用法理解的欠缺,那么get比post更快,究竟快多少呢?表现在那些方面?
一、为什么get比post更快
1.post请求包含更多的请求头
因为post需要在请求的body部分包含数据,所以会多了几个数据描述部分的首部字段(如:content-type),这其实是微乎其微的。
2.最重要的一条,post在真正接收数据之前会先将请求头发送给服务器进行确认,然后才真正发送数据
post请求的过程:
(1)浏览器请求tcp连接(第一次握手)
(2)服务器答应进行tcp连接(第二次握手)
(3)浏览器确认,并发送post请求头(第三次握手,这个报文比较小,所以http会在此时进行第一次数据发送)
(4)服务器返回100 Continue响应
(5)浏览器发送数据
(6)服务器返回200 OK响应
get请求的过程:
(1)浏览器请求tcp连接(第一次握手)
(2)服务器答应进行tcp连接(第二次握手)
(3)浏览器确认,并发送get请求头和数据(第三次握手,这个报文比较小,所以http会在此时进行第一次数据发送)
(4)服务器返回200 OK响应
也就是说,目测get的总耗是post的2/3左右,这个口说无凭,网上已经有网友进行过测试。
3.get会将数据缓存起来,而post不会
可以做个简短的测试,使用ajax采用get方式请求静态数据(比如html页面,图片)的时候,如果两次传输的数据相同,第二次以后消耗的时间将会在10ms以内(chrome测试),而post每次消耗的时间都差不多。经测试,chrome和firefox下如果检测到get请求的是静态资源,则会缓存,如果是数据,则不会缓存,但是IE什么都会缓存起来,当然,应该没有人用post去获取静态数据吧,反正我是没见过。
4.post不能进行管道化传输
http权威指南中是这样说的:http的一次会话需要先建立tcp连接(大部分是tcp,但是其他安全协议也是可以的),然后才能通信,如果 每次连接都只进行一次http会话,那这个连接过程占的比例太大了!于是出现了持久连接:在http/1.0+中是connection首部中添加keep-alive值,在http/1.1中是在connection首部中添加persistent值,当然两者不仅仅是命名上的差别,http/1.1中,持久连接是默认的,除非显示在connection中添加close,否则持久连接不会关闭,而http/1.0+中则恰好相反,除非显示在connection首部中添加keep-alive,否则在接收数据包后连接就断开了。
出现了持久连接还不够,在http/1.1中,还有一种称为管道通信的方式进行速度优化:把需要发送到服务器上的所有请求放到输出队列中,在第一个请求发送出去后,不等到收到服务器的应答,第二个请求紧接着就发送出去,但是这样的方式有一个问题:不安全,如果一个管道中有10个连接,在发送出9个后,突然服务器告诉你,连接关闭了,此时客户端即使收到了前9个请求的答复,也会将这9个请求的内容清空,也就是说,白忙活了……此时,客户端的这9个请求需要重新发送。这对于幂等请求还好(比如get,多发送几次都没关系,每次都是相同的结果),如果是post这样的非幂等请求(比如支付的时候,多发送几次就惨了),肯定是行不通的。
所以,post请求不能通过管道的方式进行通信!很有可能,post请求需要重新建立连接,这个过程不跟完全没优化的时候一样了么?所以,在可以使用get请求通信的时候,不要使用post请求,这样用户体验会更好,当然,如果有安全性要求的话,post会更好。管道化传输在浏览器端的实现还需考证,貌似默认情况下大部分浏览器(除了opera)是不进行管道化传输的,除非手动开启!
二、get传参最大长度的理解误区
1.总结
(1)http协议并未规定get和post的长度限制
(2)get的最大长度限制是因为浏览器和web服务器限制了URL的长度
(3)不同的浏览器和web服务器,限制的最大长度不一样
(4)要支持IE,则最大长度为2083byte,若支持Chrome,则最大长度8182byte
2.误解
(1)首先即使get有长度限制,也是限制的整个URL的长度,而不仅仅是参数值数据长度,http协议从未规定get/post的请求长度限制是多少
(2)所谓的请求长度限制是由浏览器和web服务器决定和设置的,各种浏览器和web服务器的设定均不一样,这依赖于各个浏览器厂家的规定或者可以根据web服务器的处理能力来设定。IE 和 Safari 浏览器 限制 2k,Opera 限制4k,Firefox 限制 8k(非常老的版本 256byte),如果超出了最大长度,大部分的服务器直接截断,也有一些服务器会报414错误。
总结
虽然上面定义了Http请求方式的使用方式,但实际开发中并不一定要完全按照上面的标准,这些指定的标准只是让我们加以参考的技术规范。实际上请求方式的意义也在于真正的业务中体现。例如:get请求方式本要求只进行查询,但实际也有些开发人员也用于了更新和删除。