HTTP协议请求：GET、HEAD，POST、PUT、DELETE等【详细介绍】

HTTP 协议的历史：

HTTP0.9

0.9协议是适用于各种数据信息的简洁快速协议，但是远不能满足日益发展的各种应用的需要。0.9协议就是一个交换信息的无序协议，仅仅限于文字。由于无法进行内容的协商，在双发的握手和协议中，并有规定双发的内容是什么，也就是图片是无法显示和处理的。

HTTP1.0

到了1.0协议阶段，也就是在1982年，Tim Berners-Lee提出了HTTP/1.0。在此后的不断丰富和发展中，HTTP/1.0成为最重要的面向事务的应用层协议。该协议对每一次请求/响应建立并拆除一次连接。其特点是简单、易于管理，所以它符合了大家的需要，得到了广泛的应用。

HTTP1.1

在1.0协议中，双方规定了连接方式和连接类型，这已经极大扩展了HTTP的领域，但对于互联网最重要的速度和效率，并没有太多的考虑。毕竟，作为协议的制定者，当时也没有想到HTTP会有那么快的普及速度。

关于HTTP1.1协议的具体内容可以参考RFC 2616。

HTTP2.0

HTTP2.0的前身是HTTP1.0和HTTP1.1。虽然之前仅仅只有两个版本，但这两个版本所包含的协议规范之庞大，足以让任何一个有经验的工程师为之头疼。网络协议新版本并不会马上取代旧版本。实际上，1.0和1.1在之后很长的一段时间内一直并存，这是由于网络基础设施更新缓慢所决定的。

关于HTTP2.0协议的具体内容可以参考RFC 7540。

Http请求响应过程

常见的HTTP协议请求简要说明：

GET：请求指定的页面信息，并返回实体主体。

HEAD：只请求页面的首部。

POST：请求服务器接受所指定的文档作为对所标识的URI的新的从属实体。

PUT：从客户端向服务器传送的数据取代指定的文档的内容。

DELETE：请求服务器删除指定的页面。

OPTIONS：允许客户端查看服务器的性能。

TRACE：请求服务器在响应中的实体主体部分返回所得到的内容。

PATCH：实体中包含一个表，表中说明与该URI所表示的原内容的区别。

MOVE：请求服务器将指定的页面移至另一个网络地址。

COPY：请求服务器将指定的页面拷贝至另一个网络地址。

LINK：请求服务器建立链接关系。

UNLINK：断开链接关系。

WRAPPED：允许客户端发送经过封装的请求。

Extension-mothed：在不改动协议的前提下，可增加另外的方法。

GET请求介绍

GET方法意思是获取被请求URI（Request-URI）指定的信息（以实体的格式）。如果请求URI涉及到一个数据生成过程，那么这个生成的数据应该被作为实体在响应中返回，但这并不是过程的资源文本，除非资源文本恰好是过程的输出（译注：URI指示的资源是动态生成的）。

如果请求消息包含 If-Modified-Since,，If-Unmodified-Since，If-Match,，If-None-Match,或者 If-Range头域，GET的语义将变成“条件（conditionall） GET”。一个条件GET方法会请求满足条件头域的实体。条件GET方法的目的是为了减少不必要的网络使用，这通过利用缓存的实体的更新，从而不用多次请求或传输客户已经拥有的数据。

如果请求方法包含一个Range头域，那么GET方法就变成“部分Get”方法。一个部分GET会请求实体的一部分，这在14.35节里描述了。 部分GET方法的目的是为了减少不必要的网络使用，这通过允许获取部分实体，从而不需要传输客户端已经拥有的数据。

GET请求的响应是可缓存的（cacheable）。

HEAD请求介绍

HEAD方法和GET方法一致，除了服务器不能在响应里返回消息主体。HEAD请求响应里HTTP头域里的元信息应该和GET请求响应里的元信息一致。此方法被用来获取请求实体的元信息而不需要传输实体主体（entity-body）。此方法经常被用来测试超文本链接的有效性，可访问性，和最近的改变……

HEAD请求的响应是可缓存的，因为响应里的信息可能被用于更新以前的那个资源的缓存实体……如果出现一个新的域值指明了缓存实体和当前源服务器上实体的不同（可能因为Content-Length，Content-MD5，ETag或Last-Modified值的改变），那么缓存（cache）必须认为此缓存项是过时的（stale）。

POST请求介绍

POST 方法被用于请求源服务器接受请求中的实体作为请求资源的一个新的从属物。POST被设计涵盖下面的功能。

• -已存在的资源的注释；

• -发布消息给一个布告板，新闻组，邮件列表，或者相似的文章组。

• -提供一个数据块，如提交一个表单给一个数据处理过程。

• -通过追加操作来扩展数据库。

POST方法的实际功能是由服务器决定的，并且经常依赖于请求URI（Request-URI）。POST提交的实体是请求URI的从属物，就好像一个文件从属于一个目录，一篇新闻文章从属于一个新闻组，或者一条记录从属于一个数据库。

POST方法执行的动作可能不会对请求URI所指的资源起作用。在这种情况下，200（成功）或者204（没有内容）将是适合的响应状态，这依赖于响应是否包含一个描述结果的实体。

如果资源被源服务器创建，响应应该是201（Created）并且包含一个实体，此实体描述了请求的状态并且此实体引用了一个新资源和一个Location头域（见14.30节）。

POST方法的响应是可缓存的。除非响应里有Cache-Control或者Expires头域指示其响应不可缓存。然而，303（见其他）响应能被利用去指导用户代理（agent）去获得可缓存的响应。

POST 请求必须遵循8.2节里指明的消息传输需求。

参见15.1.3节关于安全性的考虑。

PUT请求介绍

PUT方法请求服务器去把请求里的实体存储在请求URI（Request-URI）标识下。如果请求URI（Request-URI）指定的的资源已经在源服务器上存在，那么此请求里的实体应该被当作是源服务器此URI所指定资源实体的修改版本。如果请求URI（Request-URI）指定的资源不存在，并且此URI被用户代理（user agent，译注：用户代理可认为是客户浏览器）定义为一个新资源，那么源服务器就应该根据请求里的实体创建一个此URI所标识下的资源。如果一个新的资源被创建了，源服务器必须能向用户代理（user agent） 发送201（已创建）响应。如果已存在的资源被改变了，那么源服务器应该发送200（Ok）或者204（无内容）响应。如果资源不能根据请求URI创建或者改变，一个合适的错误响应应该给出以反应问题的性质。实体的接收者不能忽略任何它不理解的Content-*（如：Content-Range）头域，并且必须返回501（没有被实现）响应。

如果请求穿过一个缓存（cache），并且此请求URI（Request-URI）指示了一个或多个当前缓存的实体，那么这些实体应该被看作是旧的。PUT方法的响应不应该被缓存。

POST方法和PUT方法请求最根本的区别是请求URI（Request-URI）的含义不同。POST请求里的URI指示一个能处理请求实体的资源（译注：此资源可能是一段程序，如jsp里的servlet） 。此资源可能是一个数据接收过程，一个网关（gateway，译注：网关和代理服务器的区别是：网关可以进行协议转换，而代理服务器不能，只是起代理的作用，比如缓存服务器其实就是一个代理服务器），或者一个单独接收注释的实体。而PUT方法请求里有一个实体一一用户代理知道URI意指什么，并且服务器不能把此请求应用于其他URI指定的资源。如果服务器期望请求被应用于一个不同的URI，那么它必须发送301（永久移动了）响应；用户代理可以自己决定是否重定向请求。

一个独立的资源可能会被许多不同的URI指定。如：一篇文章可能会有一个URI指定当前版本，此URI区别于其文章其他特殊版本的URI。这种情况下，一个通用URI的PUT请求可能会导致其资源的其他URI被源服务器定义。

HTTP/1.1没有定义PUT方法对源服务器的状态影响。

PUT请求必须遵循8.2节中的消息传输要求。

除非特别指出，PUT方法请求里的实体头域应该被用于资源的创建或修改。

DELETE请求介绍

DELETE方法请求源服务器删除请求URI指定的资源。此方法可能会在源服务器上被人为的干涉（或其他方法）。客户端不能保证此操作能被执行，即使源服务器返回成功状态码。然而，服务器不应该指明成功除非它打算删除资源或把此资源移到一个不可访问的位置。

如果响应里包含描述成功的实体，响应应该是200（Ok）；如果DELETE动作没有通过，应该以202（已接受）响应；如果DELETE方法请求已经通过了，但响应不包含实体，那么应该以204（无内容）响应。

如果请求穿过缓存，并且请求URI（Request-URI）指定一个或多个缓存当前实体，那么这些缓存项应该被认为是旧的。DELETE方法的响应是不能被缓存的。