HTTP协议的六种请求方法

序号⽅法描述
1
GET
发送请求来获得服务器上的资源,请求体中不会包含请求数据,请求数据放在协议头中。另外get ⽀持快取、缓存
、可保留书签等。幂等
2
POST
和get ⼀样很常见,向服务器提交资源让服务器处理,⽐如提交表单、上传⽂件等,可能导致建⽴新的资源或者对
原有资源的修改。提交的资源放在请求体中。不⽀持快取。⾮幂等
3
HEAD
本质和get ⼀样,但是响应中没有呈现数据,⽽是http 的头信息,主要⽤来检查资源或超链接的有效性或是否可以可达、检
查⽹页是否被串改或更新,获取头信息等,特别适⽤在有限的速度和带宽下。
4
PUT
和post 类似,html 表单不⽀持,发送资源与服务器,并存储在服务器指定位置,要求客户端事先知
道该位置;⽐如post 是在⼀个集合上(/province ),⽽put 是具体某⼀个资源上(/province/123)。所以put 是安全的,⽆论请求多少次,都是在123上更改,⽽post 可能请求⼏次创建了⼏次资源。幂等
5DELETE 请求服务器删除某资源。和put 都具有破坏性,可能被防⽕墙拦截。如果是https 协议,则⽆需担⼼。幂等6CONNECT HTTP/1.1协议中预留给能够将连接改为管道⽅式的代理服务器。就是把服务器作为跳板,去访问其他⽹页然后把数据返回回来,连接成功后,就可以正常的get 、post 了。
7OPTIONS 获取http 服务器⽀持的http 请求⽅法,允许客户端查看服务器的性能,⽐如ajax 跨域时的预检等。8TRACE
回显服务器收到的请求,主要⽤于测试或诊断。⼀般禁⽤,防⽌被恶意攻击或盗取信息。HTTP 协议的六种请求⽅法
抛砖引⽟,聊下概念性的东西先:
HTTP 协议 (Hyper Text Transfer Protocol )
HTTP 是⼀个基于TCP/IP 通信协议来传递数据,包括html ⽂件、图像、结果等,即是⼀个客户端和服务器端请求和应答的标准。HTTP 协议特点
1.http ⽆连接:限制每次连接只处理⼀个请求,服务端完成客户端的请求后,即断开连接。(传输速度快,减少不必要的连接,但也意味着每⼀次访问都要建⽴⼀次连接,效率降低)
2.http ⽆状态:对于事务处理没有记忆能⼒。每⼀次请求都是独⽴的,不记录客户端任何⾏为。(优点解放服务器,但可能每次请求会传输⼤量重复的内容信息)
3.客户端/服务端模型:客户端⽀持web 浏览器或其他任何客户端,服务器通常是apache 或者iis 等
4.简单快速
5.灵活:可以传输任何类型的数据客户端请求消息
客户端发送⼀个请求到服务器的请求消息包括以下格式:    请求⾏,请求头部,空⾏,请求数据
(图⽚来⾃⽹络)
服务器响应消息
服务器响应包括如下格式:
状态⾏,消息报头,空⾏,响应正⽂
GET 和 POST ⽐较
GET POST
点击返回/刷新按钮没有影响数据会重新提交缓存/添加书签可以不可以历史记录
没有
编码类型
application/x-www-form-urlencoded
application/x-www-form-urlencoded
或 multipart/form-data 。为⼆进制数据使⽤多重编码
是否幂等幂等
⾮幂等
长度限制http 协议没有限制,但是实际浏览器或服务器有(最⼤2048)
理论上没有,可能会收到服务器配置或内存限制
数据类型限制只能ASCII ,⾮ascii 都要编码传输没有限制,允许⼆进制数据
安全性数据全部展⽰在url 中,不安全相⽐get ,通过request body 传递数据,⽐较安全可见效
可见
不可见注意:以上只是⼀种规范,如果⾮要给get 加上request body ,或者给post 的url 上带上参数,技术上没有任何问题。
另外曾经看到⼀篇⽂章说,get 发送1个tcp 包,⽽post 发送两个tcp 包,后来被验证这个说法是不正确的,其实get 如果也发送body ,则也会发送Expect:100
PATCH
是否幂等⾮幂等
粒度局部,最⼩粒度,节约⽹络带宽
注意:⽐如更新⼀个userinfo,包含name,age,sex等多个字段,如果只修改了age,如果⽤put来更新,则需要把其他没有变更的也要提交到服务器,但是使⽤patch,则只需要提交age到服务器即可。这都是协议层⾯来讨论的。 put请求专注于update操作,但是与之相关的是还有这个patch请求,两者虽然都专注于update操作,但是前者put是全局⽽⾔,后者patch是局限于某⼀条件或者范围⽽⾔,简单的说就是两者的粒度是不同的。
GET
请求⽰例
GET dmicro/portal/admin/getTimerInitStatus HTTP/1.1
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
Referer: dmicro/portal/admin/toLicenseTimerConfig?id=7
Accept-Language: zh-CN
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: dmicro
Connection: Keep-Alive
Cookie: _ga=GA1.2.1909963682.1524537669; _gid=GA1.2.563928490.1529501401
以上对应
第1⾏请求⾏
请求⽅法(get)+空格+url(dmicro/portal/admin/getTimerInitStatus)+空格+协议版本(HTTP/1.1)
第2-10都是请求头部
Accept:表⽰客户端接受的内容类型,按照先后顺序表⽰客户端接收数据的先后次序
X-Requested-With:以x开头的是⾮http标准,⼀般是某种技术的出现⽽定义的;这⾥是⽤来判断是http请求还是ajax请求。
Referer:从这个页⾯访问请求⾏⾥的url
Accept-Language:客户端接受内容返回优先选择的语⾔
Accept-Encoding:客户端可以接受的服务器对返回内容进⾏编码压缩的格式。
User-Agent:客户端运⾏的浏览器类型信息。
Host:头域指定请求的服务器的地址和端⼝,HTTP/1.1必须包括Host,否则返回400
Connection:表⽰是否需要持久连接。如果web服务器端看到这⾥的值为“Keep-Alive”,或者看到请求使⽤的是HTTP 1.1(HTTP 1.1默认进⾏持久连接),它就可以利⽤持久连接的优点,当页⾯包含多个元素时(例如Applet,图⽚),显著地减少下载所需要的时间。要实现这⼀点, web服务器需要在返回给客户端HTTP头信息中发送⼀个Content-Length(返回信息正⽂的长度)头,最简单的实现⽅法是:先把内容写⼊ByteArrayOutputStream,然后在正式写出内容之前计算它的⼤⼩。
Cookie:http请求时,会把保存的cookie也发送服务器。cookie是保存在客户端⾥的,分为内存cookie和硬盘cookie。前者随着浏览器关闭⽽消失,后者由过期时间或者⽤户⼿动清除。因为http请求是⽆状态的,所以服务器为了认证,会⽣成sessionid,让浏览器setcookie保存起来,每次请求携带上认证信息。这部份以后再聊吧。
响应⽰例
HTTP/1.1200 OK
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Wed, 31 Dec 196916:00:00 PST
X-Application-Context: application:prod
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 20 Jun 201815:00:16 GMT {"advancewarn":"1","userstatus":"1","ldap":"1","licensealarm":"1","deltempzipfile":"1","sctmlicense":"0","user":"1"}
第1⾏状态⾏
第2-8 消息报头
Server:包含处理请求的服务器信息,包含多个产品注释和标识。
Cache-Control:告知缓存机制是否可以缓存和类型,private是只能当前⽤户,不能被共享。
Expires:响应过期时间
X-Application-Context:application配置,这⾥表⽰读取的是application-prod.properties
Content-Type:返回数据的类型和字符编码格式
Transfer-Encoding:告知接收端,报⽂采取了何种编码,chunked表⽰服务器⽆法确定消息⼤⼩,⼀般⽐如下载等,就采⽤chunked。
Date:返回消息的时间
第 9 ⾏空⾏
第 10 ⾏响应正⽂
消息报头指定了是返回json字符串。
POST
请求⽰例
POST dmicro/portal/admin/editTimer HTTP/1.1
Host: dmicro
Connection: keep-alive
Content-Length: 35
Accept: application/json, text/javascript, */*; q=0.01
Origin: dmicro
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: dmicro/portal/admin/toAdminTimerConfig?id=7
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: _ga=GA1.2.199305797.1501211992; _ga=GA1.1.199305797.1501211992; _gid=GA1.2.56449187.1529562439; _gat_gtag_UA_111346521_2=1
type=del&interval=1200&timelag=7200
第1⾏同 get
Content-Length:告知服务器,请求数据的⼤⼩
Origin:origin类似refered,但⽐refered更⼈性化,origin只出现在post中,⽽origin也不携带敏感信息和具体url路径。
Content-Type:http请求提交内容的编码类型,⼀般只有post需要设置。application/x-www-form-urlencoded(缺省)和multipart/form-data。
第14⾏空⾏
第15⾏请求数据
响应⽰例
HTTP/1.1200 OK
Server: Apache-Coyote/1.1
X-Application-Context: application:prod
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 21 Jun 201807:36:58 GMT
{"result":"edit timer success"}
其他这⾥就不累述了。
说了这么多,这么多请求⽅式都是http协议的标准,你完全可以随⼼所欲,全部⽤post或者全部⽤get,但是你要是开发的是商业产品,那你就要为你⾃⼰的随便买单咯。好⽐删除⼀样东西,如果⽤get请求⽅式:http:/xxx/delete?id=1,那你很快就知道,这些标准也能让其他⼈⼀眼就能知道具体所要做的意思。
HTTP状态码
摘⾃
HTTP状态码分类
分类分类描述
1**信息,服务器收到请求,需要请求者继续执⾏操作
2**成功,操作被成功接收并处理
3**重定向,需要进⼀步的操作以完成请求
4**客户端错误,请求包含语法错误或⽆法完成请求
5**服务器错误,服务器在处理请求的过程中发⽣了错误
HTTP状态码列表
状态码状态码英⽂名称中⽂描述100Continue继续。应继续其请求
101Switching Protocols
切换协议。服务器根据客户端的请求切换协议。只能切换到
更⾼级的协议,例如,切换到HTTP的新版本协议
200OK请求成功。⼀般⽤于GET与POST请求
201Created已创建。成功请求并创建了新的资源
202Accepted已接受。已经接受请求,但未处理完成
203Non-Authoritative Information
⾮授权信息。请求成功。但返回的meta信息不在原始的服务器
,⽽是⼀个副本
204No Content
⽆内容。服务器成功处理,但未返回内容。在未更新⽹页
的情况下,可确保浏览器继续显⽰当前⽂档
205Reset Content
重置内容。服务器处理成功,⽤户终端(例如:浏览器)应重
置⽂档视图。可通过此返回码清除浏览器的表单域
206Partial Content部分内容。服务器成功处理了部分GET请求
300Multiple Choices
多种选择。请求的资源可包括多个位置,相应可返回⼀个
资源特征与地址的列表⽤于⽤户终端(例如:浏览器)选择
301Moved Permanently 永久移动。请求的资源已被永久的移动到新URI,返回信息
会包括新的URI,浏览器会⾃动定向到新URI。今后任何新的请求都应使⽤新的URI代替
302Found
临时移动。与301类似。但资源只是临时被移动。客户端应继
使⽤原有URI
303See Other查看其它地址。与301类似。使⽤GET和POST请求查看
304Not Modified 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何源。客户端通常会缓存访问过的资源,通过提供⼀个头信息指出客户端希望只返回在指定⽇期之后修改的资源
305Use Proxy使⽤代理。所请求的资源必须通过代理访问
306Unused已经被废弃的HTTP状态码
307Temporary Redirect临时重定向。与302类似。使⽤GET请求重定向
400Bad Request客户端请求的语法错误,服务器⽆法理解
401Unauthorized请求要求⽤户的⾝份认证
402Payment Required保留,将来使⽤
403Forbidden服务器理解请求客户端的请求,但是拒绝执⾏此请求
404Not Found 服务器⽆法根据客户端的请求到资源(⽹页)。通过此代码,⽹站设计⼈员可设置"您所请求的资源⽆法到"的个性页⾯
405Method Not Allowed客户端请求中的⽅法被禁⽌
406Not Acceptable服务器⽆法根据客户端请求的内容特性完成请求
407Proxy Authentication Required
请求要求代理的⾝份认证,与401类似,但请求者应当使⽤代
理进⾏授权
409Conflict
服务器完成客户端的PUT请求是可能返回此代码,服务器处理
请求时发⽣了冲突
410Gone 客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使⽤410代码,⽹站设计⼈员可通过301代码指定资源的新位置
411Length Required服务器⽆法处理客户端发送的不带Content-Length的请求信息412Precondition Failed客户端请求信息的先决条件错误
413Request Entity Too Large 由于请求的实体过⼤,服务器⽆法处理,因此拒绝请求。为防⽌客户端的连续请求,服务器可能会关闭连接。如果只
是服务器暂时⽆法处理,则会包含⼀个Retry-After的响应信息
414Request-URI Too Large请求的URI过长(URI通常为⽹址),服务器⽆法处理
415Unsupported Media Type服务器⽆法处理请求附带的媒体格式
416Requested range not satisfiable客户端请求的范围⽆效
417Expectation Failed服务器⽆法满⾜Expect的请求头信息
500Internal Server Error服务器内部错误,⽆法完成请求
501Not Implemented服务器不⽀持请求的功能,⽆法完成请求
502Bad Gateway充当⽹关或代理的服务器,从远端服务器接收到了⼀个⽆效的请求
503Service Unavailable
由于超载或系统维护,服务器暂时的⽆法处理客户端的请求
。延时的长度可包含在服务器的Retry-After头信息中
acceptlanguage504Gateway Time-out充当⽹关或代理的服务器,未及时从远端服务器获取请求
505HTTP Version not supported服务器不⽀持请求的HTTP协议的版本,⽆法完成处理
结束语:其实我们⼤部分情况下只⽤到了GET和POST。如果想设计⼀个符合RESTful规范的web应⽤程序,则这六种⽅法都会⽤到。不过即使暂时不想涉及REST,
了解这六种⽅法的本质仍然是很有作⽤的。⼤家将会发现,原来web也是很简洁明了的。下⾯再次依次说明这六种⽅法。
1,GET:GET可以说是最常见的了,它本质就是发送⼀个请求来取得服务器上的某⼀资源。资源通过⼀组HTTP头和呈现据(如HTML⽂本,或者图⽚或者视频等)返回给客户端。
GET请求中,永远不会包含呈现数据。
2,HEAD:HEAD和GET本质是⼀样的,区别在于HEAD不含有呈现数据,⽽仅仅是HTTP头信息。有的⼈可能觉得这个⽅法没什么⽤,其实不是这样的。
想象⼀个业务情景:欲判断某个资源是否存在,我们通常使⽤GET,但这⾥⽤HEAD则意义更加明确。
3,PUT:这个⽅法⽐较少见。HTML表单也不⽀持这个。本质上来讲, PUT和POST极为相似,都是向服务器发送数据,但它们之间有⼀个重要区别,
PUT通常指定了资源的存放位置,⽽POST则没有,POST的数据存放位置由服务器⾃⼰决定。举个例⼦:如⼀个⽤于提交博⽂的URL,/addNew。
如果⽤PUT,则提交的URL会是像这样的”/addNew/abc123”,其中abc123就是这个博⽂的地址。⽽如果⽤POST,则这个地址会在提交后由服务器告知客户端。
⽬前⼤部分博客都是这样的。显然,PUT和POST⽤途是不⼀样的。具体⽤哪个还取决于当前的业务场景。
4,DELETE:删除某⼀个资源。基本上这个也很少见,不过还是有⼀些地⽅⽐如amazon的S3云服务⾥⾯就⽤的这个⽅法来删除资源。
5,POST:向服务器提交数据。这个⽅法⽤途⼴泛,⼏乎⽬前所有的提交操作都是靠这个完成。
6,OPTIONS:这个⽅法很有趣,但极少使⽤。它⽤于获取当前URL所⽀持的⽅法。若请求成功,则它会在HTTP头中包含⼀个名为“Allow”的头,值是所⽀持的⽅法,如“GET, POST”。
我们可理解为以下:
—————————————————————
1、GET          /url/list                    查看
2、POST        /url/create                创建
3、PUT          /url/update              更新
4、DELETE    /url/delete                删除
5、HEAD        /url/is_exists            检查资源
6、PATCH      /url/update_by_id  更新某些字段
7、OPTIONS  /url/get_methods    检查请求⽅式
—————————————————————

本文发布于:2024-09-21 08:06:09,感谢您对本站的认可!

本文链接:https://www.17tex.com/tex/3/371741.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:请求   服务器   客户端   资源
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2024 Comsenz Inc.Powered by © 易纺专利技术学习网 豫ICP备2022007602号 豫公网安备41160202000603 站长QQ:729038198 关于我们 投诉建议