http请求方法（GET、POST、HEAD、OPTIONS、PUT、DELETE、TRACE、CONNECT）
HTTP的1.0版本中只有三种请求方法： GET, POST 和 HEAD方法。
到了1.1版本时，新增加了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
一、原理区别
https://blog.csdn.net/potato512/article/details/76696582
GET
- 请求指定的页面信息，并返回实体主体。
- GET请求请提交的数据放置在HTTP请求协议头中，GET方法通过URL请求来传递用户的输入，GET方式的提交你需要用Request.QueryString来取得变量的值。
- GET方法提交数据，可能会带来安全性的问题，数据被浏览器缓存。
- GET请求有长度限制
HEAD
- 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头。
POST
- 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。
- POST请求可能会导致新的资源的建立和/或已有资源的修改。
- POST方式提交时，你必须通过Request.Form来访问提交的内容
PUT
- 从客户端向服务器传送的数据取代指定的文档的内容。
DELETE
- 请求服务器删除指定的页面。
- DELETE请求一般返回3种码
- 200（OK）——删除成功，同时返回已经删除的资源。
- 202（Accepted）——删除请求已经接受，但没有被立即执行（资源也许已经被转移到了待删除区域）。
- 204（No Content）——删除请求已经被执行，但是没有返回资源（也许是请求删除不存在的资源造成的）。
CONNECT
- HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS
- 允许客户端查看服务器的性能。
TRACE
- 回显服务器收到的请求，主要用于测试或诊断。
二、详细分析
https://blog.csdn.net/gideal_wang/article/details/4316691
Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE
URL全称是资源描述符，我们可以这样认 为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删 4个操作。到这里，大家应该有个大概的了解了，GET一般用于获取/查询 资源信息，而POST一般用于更新资源信息(个人认为这是GET和POST的本质区别，也是协议设计者的本意，其它区别都是具体表现形式的差异 )。
（1）根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的 。
1.所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。
* 注意：这里安全的含义仅仅是指是非修改信息。
2.幂等的意味着对同一URL的多个请求应该返回同样的结果。
但在实际应用中，以上2条规定并没有这么严格。引用别人文章的例子：比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操 作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。从根本上说，如果目标是当用户打开一个链接时，他可以确信从自身的角度来看没有改变资源即可。
（2）根据HTTP规范，POST表示可能修改变服务器上的资源的请求 。继续引用上面的例子：还是新闻以网站为例，读者对新闻发表自己的评论应该通过POST实现，因为在评论提交后站点的资源已经不同了，或者说资源被修改了。
一般在浏览器中输入网址访问资源都是通过GET方式；在FORM提交中，可以通过Method指定提交方式为GET或者POST，默认为GET提交。
但在实际的做的时候，很多人却没有按照HTTP规范去做，导致这个问题的原因有很多，比如说：
1.很多人贪方便，更新资源时用了GET，因为用POST必须要到FORM（表单），这样会麻烦一点。
2.对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。
3.另外一个是，早期的但是Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计 。还有一个较为严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法。
* 简单解释一下MVC：MVC本来是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。
以上3点典型地描述了老一套的风格（没有严格遵守HTTP规范），随着架构的发展，现在出现REST(Representational State Transfer)，一套支持HTTP规范的新风格，这里不多说了，可以参考《RESTful Web Services》。
三、实际应用中分析
1、先看一下HTTP协议的格式：
在HTTP请求中，第一行必须是一个请求行（request line），用来说明请求类型、要访问的资源以及使用的HTTP版本。
紧接着是一个首部（header）小节，用来说明服务器要使用的附加信息。
在首部之后是一个空行，
再此之后可以添加任意的其他数据[称之为主体（body）]。
2、GET与POST方法实例：
（1）
GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive
（2）
POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
（----此处空一行----）
name=Professional%20Ajax&publisher=Wiley
1）GET提交：请求的数据会附在URL之后（就是把数据放置在请求行（request line）中），以?分割URL和传输数据，多个参数用&连接；例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。
URL的编码格式采用的是ASCII码，而不是Unicode，这也就是说你不能在URL中包含任何非ASCII字符，所有非ASCII字符均需要编码再传输，关于Url编码可参考：http://kb.cnblogs.com/page/133765/。
2）POST提交：把提交的数据放置在是HTTP包的包体中。上文示例中红色字体标明的就是实际的传输数据.
因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变。
3)传输数据的大小：首先声明：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。
而在实际开发中存在的限制主要有：
GET:特定浏览器和服务器对URL长度有限制，例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。
因此对于GET提交时，传输数据就会受到URL长度的限制。
POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。
4)安全性：
POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这 里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为
(1)登录页面有可能被浏览器缓存，
(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击