浅析Http request的8种类型、post和put的本质区别(是否幂等)、http工作原理(请求/响应模型及步骤)、request请求的url类型

一、HTTP 请求的8种方法：

　　HTTP/1.1协议中共定义了八种方法，来表明Request-URL指定的资源不同的操作方式。

　　HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。

　　HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法

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

　　下面简单介绍下这 3种

（1）OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性

（2）HEAD：与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息，用于获取报头。

（3）PUT：向指定资源位置上传其最新内容

二、post 和 put 的区别  -  是否幂等

　　有的观点认为，应该用POST来创建一个资源，用PUT来更新一个资源；有的观点认为，应该用PUT来创建一个资源，用POST来更新一个资源；还有的观点认为可以用PUT和POST中任何一个来做创建或者更新一个资源。这些观点都只看到了风格，争论起来也只是争论哪种风格更好，其实，用PUT还是POST，不是看这是创建还是更新资源的动作，这不是风格的问题，而是语义的问题。

　　在HTTP中，PUT被定义为idempotent的方法，POST则不是，这是一个很重要的区别。

“Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.”

　　上面的话就是说，如果一个方法重复执行多次，产生的效果是一样的，那就是idempotent的。

　　举一个简单的例子，假如有一个博客系统提供一个Web API，模式是这样http://superblogging/blogs/post/{blog-name}，很简单，将{blog-name}替换为我们的blog名字，往这个URI发送一个HTTP PUT或者POST请求，HTTP的body部分就是博文，这是一个很简单的REST API例子。

　　我们应该用PUT方法还是POST方法？取决于这个REST服务的行为是否是idempotent的，假如我们发送两个http://superblogging/blogs/post/Sample请求，服务器端是什么样的行为？

　　如果产生了两个博客帖子，那就说明这个服务不是idempotent的，因为多次使用产生了副作用了嘛；如果后一个请求把第一个请求覆盖掉了，那这个服务就是idempotent的。前一种情况，应该使用POST方法，后一种情况，应该使用PUT方法。

      也许你会觉得这个两个方法的差别没什么大不了的，用错了也不会有什么问题，但是你的服务一放到internet上，如果不遵从HTTP协议的规范，就可能给自己带来麻烦。比如，没准Google Crawler也会访问你的服务，如果让一个不是indempotent的服务可以用indempotent的方法访问，那么你服务器的状态可能就会被Crawler修改，这是不应该发生的

　　幂等 - 对于单个输入，如果每次都是同样的结果，则称其是幂等的。

（1）POST - 用于提交请求，可以更新或者创建资源，是非幂等的

　　举个例子，在我们的支付系统中，一个api的功能是创建收款金额二维码，它和金额相关，每个用户可以有多个二维码，如果连续调用则会创建新的二维码，这个时候就用POST。

（2）PUT - 用于向指定的 URI 传送更新资源，是幂等的

　　还是那个例子，用户的账户二维码只和用户关联，而且是一一对应的关系，此时这个 api 就可以用PUT，因为每次调用它，都将刷新用户账户二维码。

　　每次变化的 - post；每次不变的 - 可以用 put。

三、HTTP工作原理

　　HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。

　　HTTP协议采用了请求/响应模型：客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

　　HTTP 请求/响应的步骤：客户端连接到Web服务器 -> 发送Http请求 -> 服务器接受请求并返回HTTP响应 -> 释放连接TCP连接 -> 客户端浏览器解析HTML内容

（1）客户端连接到Web服务器

　　一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.baidu.com

（2）发送HTTP请求

　　通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

（3）服务器接受请求并返回HTTP响应

　　Web服务器解析请求，定位请求资源。服务器将资源副本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

（4）释放连接TCP连接

　　若 connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;

　　若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

（5）客户端浏览器解析HTML内容

　　客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

四、request 请求的 url 的类型

1、资源型 url：js/css/jpg/png/html/jsp等文件

　　资源型文件分为：

（1）静态文件：根据 url 跟本地文件系统匹配，将文件内容作为响应发送给服务器

（2）动态文件：先运行，运行完产生一个结果，再将结果作为响应发送给浏览器

　　注意：（1）默认情况下，在没有一个方法来处理资源型文件时，采用跟本地文件系统匹配的方式。（2）weblogic/tomcat 存在的意义是可以运行jsp这些java代码，不可以运行php（php用apache server来运行)、asp.net(用IIS来运行)

2、非资源型 url

　　服务器端会存在某个配置，通过这个配置，该请求被java类的某一个特定方法来处理，处理完将结果作为响应发送给浏览器或者执行foward方法将中间结果转到jsp，jsp运行后将结果作为响应发送给浏览器，一般采用转到jsp的方法。

　　注意：jsp内没有业务逻辑，只有内容展现。业务逻辑写在响应的java方法中。