前言
HTTP定义了一组请求方法,以指示要对给定资源执行的所需操作。尽管它们也可以是名词,但这些请求方法有时也称为HTTP动词。它们中的每个实现了不同的语义,但是它们的某些组共享了一些共有的功能:例如,请求方法可以是安全的,幂等的或可缓存的。
HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
序号 | ”方法 | 描述 |
---|---|---|
1 | GET | 请求指定的页面信息,并返回实体主体。 |
2 | HEAD | 类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头 |
3 | POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
5 | DELETE | 请求服务器删除指定的页面。 |
6 | CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
7 | OPTIONS | 允许客户端查看服务器的性能。 |
8 | TRACE | 回显服务器收到的请求,主要用于测试或诊断。 |
9 | PATCH | 是对 PUT 方法的补充,用来对已知资源进行局部更新 。 |
幂等性:
HTTP协议本身是一种面向资源的应用层协议,但对HTTP协议的使用实际上存在着两种不同的方式:一种是RESTful的,它把HTTP当成应用层协议,比较忠实地遵守了HTTP协议的各种规定;另一种是SOA的,它并没有完全把HTTP当成应用层协议,而是把HTTP协议作为了传输层协议,然后在HTTP之上建立了自己的应用层协议。
简单理解就是:一个HTTP方法是幂等的,指的是同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是一样的。换句话说就是,幂等方法不应该具有副作用(统计用途除外)。在正确实现的条件下,GET,HEAD,PUT和DELETE 等方法都是幂等的,而 POST 方法不是。所有的 safe 方法也都是幂等的。
幂等性只与后端服务器的实际状态有关,而每一次请求接收到的状态码不一定相同。例如,第一次调用DELETE 方法有可能返回 200,但是后续的请求可能会返回404。DELETE 的言外之意是,开发者不应该使用DELETE方法实现具有删除最后条目功能的 RESTful API。
需要注意的是,服务器不一定会确保请求方法的幂等性,有些应用可能会错误地打破幂等性约束。
GET /pageX HTTP/1.1是幂等的。连续调用多次,客户端接收到的结果都是一样的:
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
POST /add_row HTTP/1.1不是幂等的。如果调用多次,就会增加多行记录:
POST /add_row HTTP/1.1
POST /add_row HTTP/1.1 -> Adds a 2nd row
POST /add_row HTTP/1.1 -> Adds a 3rd row
DELETE /idX/delete HTTP/1.1是幂等的,即便是不同请求之间接收到的状态码不一样:
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1 -> Returns 404
常见的幂等方法:GET,HEAD, PUT,DELETE,OPTIONS
常见的非幂等方法:POST
一、GET方法
HTTP GET方法请求指定的资源。使用GET的请求应该只用于获取数据。
语法:
GET /index.html
二、HEAD方法
HTTP HEAD 方法 请求资源的头部信息,并且这些头部与 HTTP GET方法请求时返回的一致.。该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载,,以此可以节约带宽资源。
HEAD 方法的响应不应包含响应正文,即使包含了正文也必须忽略掉.。虽然描述正文信息的 entity headers,,例如 Content-Length 可能会包含在响应中,但它们并不是用来描述 HEAD 响应本身的, 而是用来描述同样情况下的 GET 请求应该返回的响应。
如果 HEAD 请求的结果显示在上一次 GET 请求后缓存的资源已经过期了,即使没有发出GET请求,缓存也会失效。
语法:
HEAD /index.html
三、POST方法
HTTP POST方法发送数据给服务器,请求主体的类型由 Content-Type 首部指定。
PUT和POST方法的区别是,PUT方法是幂等的。连续调用同一个POST可能会带来额外的影响,比如多次提交订单。
一个POST请求通常是通过HTML表单发送,并返回服务器的修改结果。在这种情况下,content type是通过在元素中设置正确的enctype 属性,或是在和元素中设置formenctype属性来选择的。
application/x-www-form-urlencoded: 数据被编码成以 '&' 分隔的键-值对,
同时以 '=' 分隔键和值. 非字母或数字的字符会被 percent-encoding:
这也就是为什么这种类型不支持二进制数据(应使用 multipart/form-data代替).
multipart/form-data
text/plain
当POST请求是通过除HTML表单之外的方式发送时,例如使用XMLHttpRequest,那么请求主体可以是任何类型。
按HTTP 1.1规范中描述,POST为了以统一的方法来涵盖以下功能:
1.注释已有的资源
2.在公告板,新闻组,邮件列表或类似的文章组中发布消息;
3.通过注册新增用户;
4.向数据处理程序提供一批数据,例如提交一个表单;
5.通过追加操作,扩展数据库数据.
语法:
POST /index.html
示例
使用默认的 application/x-www-form-urlencoded 做为 content type 的简单表单:
POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
say=Hi&to=Mom
使用 multipart/form-data 作为 content type 的表单:
POST /test.html HTTP/1.1
Host: example.org
Content-Type: multipart/form-data;boundary="boundary"
--boundary
Content-Disposition: form-data; name="field1"
value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"
value2
四、PUT方法
HTTP PUT 请求方法使用请求中的负载创建或者替换目标资源。
PUT 与 POST 方法的区别在于,PUT方法是幂等的:调用一次与连续调用多次是等价的(即没有副作用),而连续调用多次POST方法可能会有副作用,比如将一个订单重复提交多次。
语法:
PUT /new.html HTTP/1.1
请求
PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16
<p>New File</p>
响应:
如果目标资源不存在,并且PUT方法成功创建了一份,
那么源头服务器必须返回201 (Created) 来通知客户端资源已创建。
HTTP/1.1 201 Created
Content-Location: /new.html
如果目标资源已经存在,并且依照请求中封装的表现形式成功进行了更新,
那么源头服务器必须返回200 (OK) 或者204 (No Content) 来表示请求的成功完成。
HTTP/1.1 204 No Content
Content-Location: /existing.html
五、DELETE方法
HTTP DELETE请求方法用于删除指定的资源。
语法:
DELETE /file.html HTTP/1.1
示例:
请求:
DELETE /file.html HTTP/1.1
响应
如果 DELETE 方法成功执行,那么可能会有以下几种状态码:
状态码 202 (Accepted) 表示请求的操作可能会成功执行,但是尚未开始执行。
状态码 204 (No Content) 表示操作已执行,但是无进一步的相关信息。
状态码 200 (OK) 表示操作已执行,并且响应中提供了相关状态的描述信息。
HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 07:28:00 GMT
<html>
<body>
<h1>File deleted.</h1>
</body>
</html>
六、CONNECT方法
在 HTTP 协议中,CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道(tunnel)。
例如,CONNECT 可以用来访问采用了 SSL (HTTPS) 协议的站点。客户端要求代理服务器将 TCP 连接作为通往目的主机隧道,之后该服务器会代替客户端与目的主机建立连接,连接建立好之后,代理服务器会面向客户端发送或接收 TCP 消息流。
CONNECT 是一个应用范围为点到点的方法。
语法:
CONNECT www.example.com:443 HTTP/1.1
示例:
一些代理服务器在创建隧道时会要求进行身份验证。
参见 Proxy-Authorization 首部。
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
七、OPTIONS方法
HTTP的OPTIONS方法用于获取目的资源所支持的通信选项。客户端可以对特定的URL使用OPTIONS方法,也可以对整站(通过将 URL 设置为“*”)*使用该方法。
语法:
OPTIONS /index.html HTTP/1.1
OPTIONS HTTP/1.1
示例:
检测服务器所支持的请求方法
可以使用 OPTIONS 方法对服务器发起请求,以检测服务器支持哪些 HTTP 方法:
curl -X OPTIONS http://example.org -i
响应报文包含一个 Allow 首部字段,该字段的值表明了服务器支持的所有 HTTP 方法:
HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Expires: Thu, 20 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
x-ec-custom-error: 1
Content-Length: 0
CORS 中的预检请求:
在 CORS 中,可以使用 OPTIONS 方法发起一个预检请求,以检测实际请求是否可以被服务器所接受。预检请求报文中的 Access-Control-Request-Method 首部字段告知服务器实际请求所使用的 HTTP 方法;Access-Control-Request-Headers 首部字段告知服务器实际请求所携带的自定义首部字段。服务器基于从预检请求获得的信息来判断,是否接受接下来的实际请求。
请求:
OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
服务器所返回的Access-Control-Allow-Methods首部字段将所有允许的请求方法告知客户端。
该首部字段与 Allow 类似,但只能用于涉及到 CORS 的场景中。
响应:
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
八、TRACE方法
HTTP TRACE方法实现沿通向目标资源的路径的消息环回(loop-back)测试 ,提供了一种实用的 debug 机制。
请求的最终接收者应当原样反射(reflect)它接收到的消息,除了以下字段部分,作为一个Content-Type 为 message/http 的200(OK)响应的消息的主体(body)返回给客户端 。
最终接收者是指初始(origin)服务器,或者第一个接收到 Max-Forwards 值为 0的请求的服务器。
语法:
TRACE /index.html
九、PATCH方法
在HTTP协议中,请求方法 PATCH 用于对资源进行部分修改。
在HTTP协议中,PUT方法已经被用来表示对资源进行整体覆盖, 而POST方法则没有对标准的补丁格式的提供支持。不同于 PUT 方法,而与 POST 方法类似,PATCH 方法是非幂等的,这就意味着连续多个的相同请求会产生不同的效果。
要判断一台服务器是否支持PATCH方法,那么就看它是否将其添加到了响应首部Allow或者 Access-Control-Allow-Methods(在跨域访问的场合,CORS)的方法列表中 。
另外一个支持 PATCH方法的隐含迹象是Accept-Patch 首部的出现,这个首部明确了服务器端可以接受的补丁文件的格式。
语法:
PATCH /file.txt HTTP/1.1
示例:
请求:
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100
[description of changes]
响应:
204 状态码表示这是一个操作成功的响应,因为响应中不带有消息主体。
HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"