2.2.2 HTTP 请求方法

HTTP 请求方法

这里的名词“方法”(method)是面向对象技术中使用的专门名词；所谓“方法”就是对所请求的对象进行的操作，这些方法实际上也就是一些命令；而 HTTP 请求方法就是 HTTP 请求报文对服务器的操作；

因此，请求报文的类型是由它所采用的方法决定的；

根据 HTTP 标准，HTTP 可以使用多种请求方法来表明对 Request-URI 指定的资源的不同操作方式；

1. HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法；
2. HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法；

方法	描述	支持的HTTP协议版本
GET		1.0、1.1
POST		1.0、1.1
HEAD		1.0、1.1
PUT		1.0、1.1
PATCH		1.0、1.1
DELETE		1.0、1.1
CONNECT		1.1
OPTIONS		1.1
TRACE		1.1
LINK	建立和资源之间的联系	1.0
UNLINE	断开连接关系	1.0

虽然 HTTP 的请求方式有很多种，但是我们在实际应用中常用的也就是 get 和 post，其他请求方式也都可以通过这两种方式间接的来实现；

GET

GET可以说是最常见的了，Get 方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等；

HTTP 协议没有为 GET 请求的 body 赋予语义，也就是即不要求也不禁止 GET 请求带 body；

大多数 HTTP 实现从技术上都支持 HTTP GET 请求带 body，少数实现会禁止（google-chrome 浏览器、node-fetch），少数实现会不建议（Fiddler）；

软件工程中有一条原则：不要依赖未定义的行为；

HTTP 协议未定义 GET 请求的 body 语义，如果想用 GET 请求发送 body，得先为其定义语义，并确保上下游都能很好的支持；

作为服务接口的提供方，不应该假设所有的调用方都能发出 GET 请求 body；作为调用方，不应该假设服务方能完美解析 GET 请求 body，但如果服务方提供了支持 GET 请求 body 的接口，可以放心使用，不用纠结；

软件工程中还有另一条原则，翻译成中国的老话就是：严于律己，宽已待人；我们在写库、写框架、写工具时应该支持 GET 请求带 body；在封装接口时，尽量不要强制调用方用 GET body 提交数据，除非遇到用 GET body 才符合逻辑的特殊情况；在使用别人提供的库、框架、工具，或者调用协作方提供的接口时不应该强求对方支持 GET 请求 body；

POST

和 get 相反，POST 方法用来向指定资源提交数据进行处理请求（例如提交表单或者上传文件）；

数据被包含在请求体中，POST 请求可能会导致新的资源的建立和/或已有资源的修改；

虽然用GET 方法也可以传输实体的主体，但一般不用GET 方法进行传输，而是用POST 方法；虽说POST 的功能与GET 很相似，但POST 的主要目的并不是获取响应的主体内容；

Get和post区别

GET	POST
GET请求传递的数据是放在HTTP包头中的，也就是URL之后；	Post是把提交的数据放在HTTP报文主体中的；
GET提交的数据比较少，最多1024B；	POST可以传送更多的数据（理论上是没有限制的，但一般也 会受不同的环境，如浏览器、操作系统、服务器处理能力等 限制）；
Get时，参数数据是明文传输的，参数直接暴露在url中，get请求参数会被完整保留在浏览历史记录里；但GET的速度可能会快些；	post中的参数不会被保留； 所以Post的安全性要比Get高，POST数据则可以加密的；
get请求只能进行url编码。	post支持多种编码方式。
GET和POST本质上就是TCP链接，GET产生一个TCP数据包；	POST产生两个TCP数据包；
GET方式的请求，浏览器会把http header和data—并发送出去；服务器响应200(返回数据)；	POST请求，浏览器先发送header，服务器响应100 continue；浏览器再发送data，服务器响应200(返回数据)；
在 HTTP 协议里，安全和幂等的概念： 所谓的「安全」是指请求方法不会「破坏」服务器上的资源； 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的；
GET 方法是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的；	POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的；

PUT

PUT这个方法比较少见，HTML表单也不支持这个；

本质上来讲，PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置（报文中的URL），而POST则没有，POST的数据存放位置由服务器自己决定；

举个例子：

如一个用于提交博文的URL——/addBlog；如果用PUT，则提交的URL会是像这样的/addBlog/abc123，其中abc123就是这个博文的地址；而如果用POST，则这个地址会在提交后由服务器告知客户端，目前大部分博客都是这样的；

显然，PUT和POST用途是不一样的，具体用哪个还取决于当前的业务场景；

PUT 方法用来传输文件，就像FTP 协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求URI 指定的位置；

但是，鉴于HTTP/1.1 的PUT 方法自身不带验证机制，任何人都可以上传文件，存在安全性问题，因此一般的Web 网站不使用该方法；

若配合Web 应用程序的验证机制，或架构设计采用REST（REpresentational State Transfer，表征状态转移）标准的同类Web 网站，就可能会开放使用PUT 方法；

HEAD

HEAD 方法和 GET 方法一样本质是一样的，区别在于 HEAD 的响应报文不返回报文主体部分，而仅仅是HTTP头信息；

有的人可能觉得这个方法没什么用，其实不是这样的；这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息，常用于确认URI 的有效性及资源更新的日期时间等；

想象一个业务情景：

        欲判断某个资源是否存在，我们通常使用GET，但这里用HEAD则意义更加明确；

DELETE

DELETE方法用来删除文件，是与PUT相反的方法；DELETE方法按请求 URI 删除 URI 所标识的资源；

但是，HTTP/1.1 的 DELETE 方法本身和PUT 方法一样不带验证机制，所以一般的Web 网站也不使用DELETE 方法；

当配合Web 应用程序的验证机制，或遵守REST 标准时还是有可能会开放使用的；

比如：amazon的S3云服务里面就用的这个方法来删除资源；

OPTIONS

OPTIONS方法用来查询针对请求 URI 指定的资源支持的请求方法；

OPTIONS这个方法很有趣，但极少使用；它用于获取当前URL所支持的请求方法；

若请求成功，则响应报文会在HTTP头中包含一个名为Allow的头字段，值是请求URL所支持的请求方法，如GET，POST；

PATCH

PATCH是对 PUT 方法的补充，用来对已知资源进行局部更新；

TRACE

TRACE方法是让Web 服务器端将之前的请求通信环回给客户端的方法；即TRACE 请求服务器回送收到的请求信息，主要用于测试和诊断，所以是安全的；

发送请求时，在Max-Forwards 首部字段中填入数值，每经过一个服务器端就将该数字减1，当数值刚好减到0 时，就停止继续传输，最后接收到请求的服务器端则返回状态码200 OK 的响应；

客户端通过TRACE方法还可以查询发送出去的请求是怎样被加工修改/ 篡改的；这是因为，请求想要连接到源目标服务器可能会通过代理中转，TRACE 方法就是用来确认连接过程中发生的一系列操作；

但是，TRACE方法本来就不怎么常用，再加上它容易引发 XST（Cross-Site Tracing，跨站追踪）攻击，通常就更不会用到了；

CONNECT

CONNECT 方法用于在与代理服务器通信时建立隧道，实现用隧道协议进行TCP 通信；主要使用SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输；

这个方法的作用其实就是把服务器作为跳板，让服务器代替用户去访问其它网页，之后把数据原原本本的返回给用户；

CONNECT 方法的“请求行”格式如下所示：

        CONNECT 代理服务器名:端口号 HTTP版本