常见的HTTP Method深度解析

HTTP版本

在HTTP的发展过程当中，出现了不少HTTP版本，其中的大部分协议都是向下兼容的。在进行HTTP请求时，客户端在请求时会告诉服务器它采用的协议版本号，而服务器则会在使用相同或者更早的协议版本进行响应。

HTTP/0.9

这是HTTP最先大规模使用的版，现已过期。在这个版本中 只有GET一种请求方法，在HTTP通信也没有指定版本号，也不支持请求头信息。该版本不支持POST等方法，所以客户端向服务器传递信息的能力很是有限。

HTTP/1.0

这个版本是第一个在HTTP通信中指定版本号的协议版本，HTTP/1.0至今仍被普遍采用，特别是在代理服务器中。

HTTP/1.0支持：GET、POST、HEAD三种HTTP请求方法。

HTTP/1.1

HTTP/1.1是当前正在使用的版本。该版本默认采用持久链接，并能很好地配合代理服务器工做。还支持以管道方式同时发送多个请求，以便下降线路负载，提升传输速度。

HTTP/1.1新增了：OPTIONS、PUT、DELETE、TRACE、CONNECT五种HTTP请求方法。

HTTP/2

这个版本是最新发布的版本，于今年5月（2015年5月）作HTTP标准正式发布。HTTP/2经过支持请求与相应的多路重用来减小延迟，经过压缩HTTP头字段将协议开销降到最低，同时增长了对请求优先级和服务器端推送的支持。

HTTP Method

GET

GET 是最经常使用的方法。一般用于请求服务器发送某个资源。HTTP/1.1 要求服务器实现此方法。

HEAD

HEAD 方法与 GET 方法的行为很相似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就容许客户端在未获取实际资源的状况下，对资源的首部进行检查。使用 HEAD，能够:

• 在不获取资源的状况下了解资源的状况(好比，判断其类型);
• 经过查看响应中的状态码，看看某个对象是否存在;
• 经过查看首部，测试资源是否被修改了。

服务器开发者必须确保返回的首部与 GET 请求所返回的首部彻底相同。遵循 HTTP/1.1 规范，就必须实现 HEAD 方法。

PUT

与 GET 从服务器读取文档相反，PUT 方法会向服务器写入文档。有些发布系统容许用户建立 Web 页面，并用 PUT 直接将其安装到 Web 服务器上去。

PUT 方法的语义就是让服务器用请求的主体部分来建立一个由所请求的 URL 命名的新文档，或者，若是那个 URL 已经存在的话，就用这个主体来替代它。

由于 PUT 容许用户对内容进行修改，因此不少 Web 服务器都要求在执行 PUT 以前，用密码登陆。

和POST方法同样，PUT方法也改变了资源的状态，因此是 非安全 的。可是有一点和POST不一样，它是 幂等 的，这是为何呢？想一想setter函数吧，重复调用，只要参数是同样的，表述就是不变的。

POST

POST 方法起初是用来向服务器输入数据的。实际上，一般会用它来支持 HTML 的表单。表单中填好的数据一般会被送给服务器，而后由服务器将其发送到它要去的地方(好比，送到一个服务器网关程序中，而后由这个程序对其进行处理)。

注： POST 用于向服务器发送数据。PUT 用于向服务器上的资源(例如文件)中存储数据。

TRACE

客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其余一些应用程序。每一个中间节点均可能会修改原始的 HTTP 请求。TRACE 方法容许客户端在 最终将请求发送给服务器时，看看它变成了什么样子。

TRACE 请求会在目的服务器端发起一个 环回 诊断。行程最后一站的服务器会弹回一条 TRACE 响应，并在响应主体中携带它收到的原始请求报文。这样客户端就能够查看在全部中间 HTTP 应用程序组成的请求 / 响应链上，原始报文是否，以及如何被毁坏或修改过。

TRACE 方法主要用于诊断；也就是说，用于验证请求是否如愿穿过了请求 / 响应链。它也是一种很好的工具，能够用来查看代理和其余应用程序对用户请求所产生 效果。

尽管 TRACE 能够很方便地用于诊断，但它确实也有缺点，它假定中间应用程序对各类不一样类型请求(不一样的方法——GET、HEAD、POST 等)的处理是相同的。

不少 HTTP 应用程序会根据方法的不一样作出不一样的事情——好比，代理可能会将 POST 请求直接发送给服务器，而将 GET 请求发送给另外一个 HTTP 应用程序(好比 Web 缓存)。TRACE 并不提供区分这些方法的机制。一般，中间应用程序会自行决定对 TRACE 请求的处理方式。

TRACE 请求中不能带有实体的主体部分。TRACE 响应的实体主体部分包含了响应服务器收到的请求的精确副本。

当 TRACE 请求到达目的服务器时，16 整条请求报文都会被封装在一条 HTTP 响应的主体中回送给发送端。当 TRACE 响应到达时，客户端能够检查服务器收到的确切报文，以及它所通过的代理列表(在 Via 首部)。TRACE 响应的 Content-Type 为 message/http，状态为 200 OK。

Via

Via 首部字段列出了与报文途经的每一个中间节点(代理或网关)有关的信息。报文每通过一个节点，都必须将这个中间节点添加到 Via 列表的末尾。

代理也能够用 Via 首部来检测网络中的路由循环。代理应该在发送一条请求以前， 在 Via 首部插入一个与其自身有关的独特字符串，并在输入的请求中查找这个字符 串，以检测网络中是否存在路由循环。

Via 首部字段包含一个由逗号分隔的 路标(waypoint)。每一个路标都表示一个独立的 代理服务器或网关，且包含与那个中间节点的协议和地址有关的信息。下面是一个 带有两个路标的 Via 首部实例:

Via = 1.1 cache.joes-hardware.com, 1.1 proxy.irenes-isp.net

Via 首部的正规语法以下所示:

Via = "Via" ":" 1#( waypoint )
waypoint = ( received-protocol received-by [ comment ] ) 
received-protocol = [ protocol-name "/" ] protocol-version 
received-by = ( host [ ":" port ] ) | pseudonym

注意，每一个 Via 路标中最多包含 4 个组件:一个可选的协议名(默认为 HTTP)、一 个必选的协议版本、一个必选的节点名和一个可选的描述性注释。

OPTIONS

OPTIONS 方法请求 Web 服务器告知其支持的各类功能。能够询问服务器一般支持哪些方法，或者对某些特殊资源支持哪些方法。(有些服务器可能只支持对一些特殊类型的对象使用特定的操做)。

经过使用 OPTIONS，客户端能够在与服务器进行交互以前，肯定服务器的能力，这样它就能够更方便地与具有不一样特性的代理和服务器进行互操做了。

这为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能断定访问各类资源的最优方式。

若是 OPTIONS 请求的 URI 是个星号(*)，请求的就是整个服务器所支持的功能。

好比:

OPTIONS * HTTP/1.1

若是 URI 是个实际资源地址，OPTIONS 请求就是在查询那个特定资源的可用特性:

OPTIONS http://www.joes-hardware.com/index.html HTTP/1.1

若是成功，OPTIONS方法就会返回一个包含了各类首部字段的200 OK响应，这些 字段描述了服务器所支持的，或资源可用的各类可选特性。HTTP/1.1 在响应中惟一 指定的首部字段是 Allow 首部，这个首部用于描述服务器所支持的各类方法(或者 服务器上的特定资源)。OPTIONS 容许在可选的响应主体中包含更多的信息，但并无对这种用法进行定义。

Allow首部

Allow 实体首部字段列出了请求 URI 标识的资源所支持的方法列表，若是请求 URI为 * 的话，列出的就是整个服务器所支持的方法列表。例如:

Allow: GET, HEAD, PUT

能够将 Allow 首部做为请求首部，建议在新的资源上支持某些方法。并不要求服务 器支持这些方法，但应该在相应的响应中包含一个 Allow 首部，列出它实际支持的方法。

由于客户端可能已经经过其余途径与原始服务器进行了交流，因此即便代理没法理解指定的全部方法，也不能对 Allow 首部字段进行修改。

DELETE

顾名思义，DELETE 方法所作的事情就是请服务器删除请求 URL 所指定的资源。 可是，客户端应用程序没法保证删除操做必定会被执行。由于 HTTP 规范容许服务 器在不通知客户端的状况下撤销请求。

和POST方法同样，DELETE方法也改变了资源的状态，因此是非安全的。可是有一点和POST不一样，它是幂等的，也就是说，就算是服务器在前一个请求中已经删除了资源，它也必须返回200.这就意味着，咱们在实现服务端的该方法是，须要跟踪已经删除的资源，不然就会返回404的。

CONNECT

CONNECT方法是HTTP/1.1协议预留的，可以将链接改成管道方式的代理服务器。一般用于SSL加密服务器的连接与非加密的HTTP代理服务器的通讯。

PATCH

PATCH方法出现的较晚，它在2010年的 RFC 5789 PATCH Method for HTTP 标准中被定义。PATCH请求与PUT请求相似，一样用于资源的更新。两者有如下两点不一样：

• 但PATCH通常用于资源的部分更新，而PUT通常用于资源的总体更新。
• 当资源不存在时，PATCH会建立一个新的资源，而PUT只会对已在资源进行更新。

参考

• HTTP 权威指南
• RFC 7231, section 4: Request methods
• RFC 5789, section 2: Patch method