HTTP请求方法总结

      HTTP请求方法并不是只有GET和POST，只是最常用的。据RFC2616标准（现行的HTTP/1.1）得知，通常有以下8种方法：OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE和CONNECT。

      一、HEAD方法跟GET方法相同，只不过服务器响应时不会返回消息体。一个HEAD请求的响应中，HTTP头中包含的元信息应该和一个GET请求的响应消息相同。这种方法可以用来获取请求中隐含的元信息，而不用传输实体本身。也经常用来测试超链接的有效性、可用性和最近的修改。

一个HEAD请求的响应可被缓存，也就是说，响应中的信息可能用来更新之前缓存的实体。如果当前实体跟缓存实体的阈值不同（可通过Content-Length、Content-MD5、ETag或Last-Modified的变化来表明），那么这个缓存就被视为过期了。

    HEAD请求常常被忽 略，但是能提供很多有用的信息，特别是在有限的速度和带宽下。主要有以下特点：

1、只请求资源的首部；

2、检查超链接的有效性；

3、检查网页是否被修改；

4、多用于自动搜索机器人获取网页的标志信息，获取rss种子信息，或者传递安全认证信息等

 

 

      二、GET方法用来获取Request-URI标识的任何（实体形式的）信息。如果Request-URI是关于一个数据处理过程，则应在响应中返回产生的数据，而不是过程中的源文本，除非该文本碰巧就是输出。

如果请求消息头包含If-Modified-Since、If-Unmodified-Since、If-Match、If-None-Match或If-Range，则GET方法的语义就变为“conditional GET”。只有在有条件的头域描述下，此conditional GET方法的请求才能传输。这种conditional GET方法试图通过刷新缓存实体来减少不必要的网络使用，避免多次请求或传输客户端已有的数据。

如果请求消息头包含Range，则GET方法的语义就变为“partial GET”。partial GET方法只请求传输实体的一部分。这种partial GET方法试图通过补全这些部分取回的实体来减少不必要的网络使用，避免传输客户端已有的数据。

    GET请求方法是最常用的HTTP请求之一，有以下几个特点：

1、是默认的请求方法；

2、GET请求通常用于获取信息，而不是修改，所以应该是安全的、幂等的。

3、请求数据表现在URL上，以名称/值的形式发送。通常URL的长度限制为2KB，对于正常请求，基本不会超出该限制，除非是XML。

4、在IE和Opera等浏览器会产生URL缓存。如果不增加冗余的请求参数，响应会返回缓存中数据，导致结果不一致。

5、安全性低。不过POST请求也只比GET请求更安全一点点，获取开放的POST数据也是轻而易举的事，除非使用安全的网络连接，例如SSL。

 

 

      三、POST方法用来请求原始服务器接受请求中包含的实体，附属于Request-Line中的Request-URI标识资源。POST用来完成以下功能：

• 标注已存在的资源；
• 在论文、新闻组、邮件列表或此类的文章组上发表信息；
• 向数据处理过程提交数据块，例如提交表单的结果；
• 通过追加的操作来拓展数据库

POST方法实际完成的功能取决于服务器，并且通常依赖于Request-URI。发送的实体属于URI，就像一个文件属于一个目录、一篇新闻文章属于它所发表的新闻组、或者一条记录属于一个数据库 。

POST方法完成的行为可能不会产生一个URI标识的资源。在这种情况下，200（OK）或204（No Content）都是适合的响应状态，取决于响应是否包含描述结果的实体。

如果原始服务器上已经创建了资源，则响应应该是201（Created），并且包含一个描述请求状态的实体、一个新资源的引用，和一个Location头。

这种方法的响应不能缓存，除非该响应包含适合的Cache-Control或Expires头域。不过，303响应可以用来引导用户获取缓存的资源。

        POST请求必须遵守信息传输要求

        POST是最常用的请求方法之一，和GET方法的最大区别就是发送的数据和URL分离，因此没有长度限制。如果使用POST方法，还应将请求头中的Content-type设为application/x-www-form-urlencoded。POST方法有以下特点：

1、主要用于向服务器传送数据，例如发表博文，而GET主要用于获取；

2、数据封装在请求中，而不是URL中，因此没有长度限制；

3、不能缓存，而GET请求会缓存，在IE等浏览器中会直接返回缓存数据。

 

      四、PUT方法请求那些封装在Request-URI的实体。如果Request-URI引用一个已存在的资源，则该封装实体应该作为原始服务器上的修改版本。如果Request-URI不是指向一个已存在的资源，并且该URI可被请求的用户代理定义为新资源，则原始服务器可用此URI创建新的资源。如果新资源被创建，这个原始服务器就必须通过201（Created）响应通知用户代理。如果已有资源被修改，则应发送200（OK）或204（No Content）响应，表示成功完成了该请求。如果Request-URI既没有创建也没用修改资源，则应给予适当的错误响应来反映问题本质。实体的接受者不能忽略任何不理解或没有实现的Content-*（例如 Content-Range）头部，并且必须返回501（Not Implemented）响应。

如果请求经过缓存，并且Rrequest-URI标识出一个或多个当前缓存的实体，则那些实体视为过期了。该方法的响应不会被缓存。

POST和PUT请求的根本区别在于Request-URI的不同意义。POST请求中的URI表示处理该封闭实体的资源，该资源可能是个数据接收过程、某种协议的网关、或者接收注解的独立实体。然而，PUT请求中的URI表示请求中封闭的实体--用户代理知道URI的目标，并且服务器无法将请求应用到其他资源。如果服务器希望该请求应用到另一个URI，就必须发送一个301（Moved Permanently）响应；用户代理可通过自己的判断来决定是否转发该请求。

不同的URI可以标识同一个资源。例如，一篇文章可以用“当前版本”URI来标识，区别于其他特殊版本的URI。这种情况下，一个通过URI的PUT请求可以获取原始服务器上定义的其他URI。

HTTP/1.1没有定义一个PUT请求如何影响原始服务器的状态。

PUT请求必须遵守信息传输要求。

除非另有说明，PUT请求中的实体头部应该用于PUT创建或修改的资源上。

PUT方法通常用于向服务器发送请求，如果URI不存在，则要求服务器根据请求创建资源，如果存在，服务器就接受请求内容，并修改URI资源的原始版本。就是通常俗称的上传资源。