常见的HTTP请求方法
一、概述
HTTP一共定义了九种请求方法：
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
二、请求方法分类总结
1. GET
用于请求指定的页面信息，并返回实体主体。
GET请求是安全且幂等的。所谓安全是指该操作用于获取信息而非修改信息，所谓幂等是指对同一个URL的多个请求应该返回同样的结果。GET请去的参数拼接在其URL上。
GET请求的一些其他特性：
GET请求可能被缓存GET请求保留在浏览器历史记录中GET请求可被收藏为书签GET请求不应在处理敏感数据时使用GET请求有长度限制GET请求只应当用于取回数据（不修改）
2. HEAD
类似于GET请求，只不过返回的响应中没有具体的内容，用于获取报头。
它的好处在于，不必传输全部内容，就可以获取其中关于该资源的信息（元信息或元数据），对资源的首部进行检查，比如：
- 如果
GET/users返回用户列表； - 那么
HEAD/users将发出相同的请求，但不会返回用户列表。
3. POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件），数据被包含在请求体中，POST请求可能会导致新的资源的建立或已有资源的修改。每次提交，表单的数据被浏览器编码到HTTP请求的body里。
浏览器发出的POST请求的body主要格式：
application/x-www-form-urlencoded：用来传输简单的表单数据，如key1=value1&key2=value2;multipart/form-data：主要用来传输文件内容；application/json：主要告诉服务端消息主体是序列化后的JSON字符串；text/plain：纯文本格式。
采用 multipart/form-data 是因为 application/x-www-form-urlencoded 的编码方式对于文件这种二进制的数据非常低效。 除了原生的content-type，开发人员也可以完全自定义数据提交格式！
POST请求的其他特性：
POST请求不会被缓存POST请求不会保留在浏览器历史记录中POST不能被收藏为书签POST请求对数据长度没有要求
4. OPTIONS
允许客户端查看服务器性能。
客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法。
若请求成功，则它会在 HTTP 头中包含一个名为 “Allow” 的头，值是所支持的方法，如 “GET, POST”。
可以使用 OPTIONS 方法对服务器发起请求，以检测服务器支持哪些 HTTP 方法，响应报文包含一个 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
5. PUT
从客户端向服务器传送的数据取代指定的文档的内容。
PUT与POST方法的区别在于，PUT方法是幂等的，调用一次与调用多次是等价的，即没有副作用，而调用多次POST方法可能会有副作用，如将一个订单重复提交多次。
PUT方法可能的响应：
- 如果目标资源不存在，并且
PUT方法成功创建了一份，那么源头服务器必须返回201(created)来通知客户端资源已创建； - 如果目标资源存在，并且按照请求中封装的方法进行了更新，那么，源头服务器必须返回
200(ok)或者204(No Content)来表示请求的成功完成。
6. PATCH
是对PUT方法的补充，用来对已知资源进行局部更新。
在HTTP协议中， PUT 方法已经被用来表示对资源进行整体覆盖， 而 POST 方法则没有对标准的补丁格式的提供支持。不同于 PUT 方法，而与 POST 方法类似，PATCH 方法是非幂等的，这就意味着连续多个的相同请求会产生不同的效果。
要判断一台服务器是否支持 PATCH 方法，那么就看它是否将其添加到了响应首部 Allow 或者 Access-Control-Allow-Methods （在跨域访问的场合，CORS）的方法列表中 。
另外一个支持 PATCH 方法的隐含迹象是 Accept-Patch 首部的出现，这个首部明确了服务器端可以接受的补丁文件的格式。
7. DELETE
请求服务器删除指定的页面。
DELETE 方法就是请求服务器删除指定 URL 所对应的资源。但是，客户端无法保证删除操作一定会被执行，因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。
如果 DELETE 方法成功执行，那么可能会有以下几种状态码：
- 状态码
202 (Accepted)表示请求的操作可能会成功执行，但是尚未开始执行。 - 状态码
204 (No Content)表示操作已执行，但是无进一步的相关信息。 - 状态码
200 (OK)表示操作已执行，并且响应中提供了相关状态的描述信息。
8. TRACE
回显服务器收到的请求，主要用于测试或诊断。
请求的最终接收者应当原样反射（reflect）它接收到的消息，作为一个 Content-Type 为 message/http 的200（OK）响应的消息的主体（body）返回给客户端 。
最终接收者是指初始（origin）服务器，或者第一个接收到 Max-Forwards 值为 0的请求的服务器。
我们都知道，客户端在发起一个请求时，这个请求可能要穿过防火墙、代理、网关、或者其它的一些应用程序。这中间的每个节点都可能会修改原始的 HTTP 请求。由于有一个“回环”诊断，在请求最终到达服务器时，服务器会弹回一条 TRACE 响应，并在响应主体中携带它收到的原始请求报文的最终模样。这样客户端就可以查看 HTTP 请求报文在发送的途中，是否被修改过了。
9. CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道。
三、get和post区别
最直观的就是语义上的区别
- get用来获取数据，post用来提交数据
- get参数有长度限制（受限于url长度，具体的数值取决于浏览器和服务器的限制，最长2048字节），而post无限制。
- get请求的数据会附加在url之 ，以 " ？ "分割url和传输数据，多个参数用 "&"连接，而post请求会把请求的数据放在http请求体中。
- get是明文传输，post是放在请求体中，但是开发者可以通过抓包工具看到，也相当于是明文的。
- get请求会保存在浏览器历史记录中，还可能保存在web服务器的日志中
首先get和post在本质上都是tcp链接，但由于http协议和浏览器或者服务器的限制，从而使它们在应用过程中产生了差别，但是它们中还有一个较大的区别：get在请求时发送一个数据包，会将header和data一起发送过去，而post会产生两个数据包先发送header，服务器返回100，然后在发送data，服务器返回200
四、form表单可以提交get请求吗？
答案是可以的，只需将form的method设置为get即可，发出的也是一个正常的get请求。
表象上的区别：
- get无消息体
- post一般没有查询参数
- get有URL长度限制。由于get有查询参数，如果get的url超过服务器设置的范围，会得到414错误。
- 安全性。post比get安全。因为构造post请求比get请求难。
事实上： get和post只有语义上的区别，get代表获取内容，post代表上传内容。
- 其实get也可以有消息体，只是由于它是去拿内容，没必要携带自身的信息。
- post也可以有查询参数（在action属性里加）。get/post都有长度限制，长度限制由服务器设置，可以改写。
- get和post都不安全，如果要安全，需要用https或者客户端的技术。