HTTP 请求方法一览表 ​

本页列出了所有 HTTP 支持的请求方法，涵盖GET、POST、PUT、DELETE等常用方法及CONNECT、OPTIONS、TRACE等特殊方法，详解其功能、用途及RFC规范引用

1. GET方法 ​

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

  • 获取资源GET方法请求传输目标资源的当前选定表示形式。GET是信息检索的主要机制，也是几乎所有性能优化的焦点。因此，当人们谈到通过HTTP检索一些可识别信息时，他们通常指的是发出GET请求。

GET 方法具体见 RFC 7231 规范 - 第4.3.1节 。

2. HEAD方法 ​

类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头。

  • HEAD方法与GET方法相同，只是服务器不能在响应中发送消息体（即，响应终止于header部分的末尾）。服务器响应HEAD请求时应发送与请求为GET时相同的报头字段，但可省略有效负载报头字（段RFC 7231 规范 - 第3.3节）。此方法可用于在不传输表示数据的情况下获取所选表示的元数据，并且通常用于测试超文本链接的有效性、可访问性和最近的修改。

HEAD 方法具体见 RFC 7231 规范 - 第4.3.2节 。

3. POST方法 ​

向指定资源提交数据进行处理请求，数据被包含在请求体中。

  • POST方法请求目标资源根据资源自身的特定语义处理请求中包含的表示。例如，POST用于以下功能（除其他功能外）：
    • 向数据处理过程提供数据块，例如输入HTML表单的字段；
    • 向公告栏、新闻组、邮件列表、博客或类似文章组发布消息；
    • 创建尚未由源服务器标识的新资源;
    • 将数据附加到资源的现有表示形式。

POST 方法具体见 RFC 7231 规范 - 第4.3.3节 。

4. PUT方法 ​

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

  • PUT方法请求创建目标资源的状态，或将其替换为请求消息负载中包含的表示所定义的状态。对给定表示的成功PUT将表明，对同一目标资源的后续GET将导致在200（OK）响应中发送等效表示。然而，不能保证这种状态变化是可以观察到的，因为在接收任何后续GET之前，目标资源可能会由其他用户代理并行操作，或者可能会受到源服务器的动态处理。成功的响应仅意味着用户代理的意图是在源服务器处理时实现的。

  • POST和PUT方法之间的根本区别在于所附表示的不同意图。POST请求中的目标资源旨在根据资源自身的语义处理封闭表示，而PUT请求中的封闭表示被定义为替换目标资源的状态。因此，PUT的意图是幂等的，并且对中介体可见，即使确切的效果只有源服务器知道。

PUT 方法具体见 RFC 7231 规范 - 第4.3.4节 。

5. DELETE方法 ​

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

  • DELETE方法请求源服务器删除目标资源与其当前功能之间的关联。实际上，此方法类似于UNIX中的rm命令：它表示对源服务器的URI映射的删除操作，而不是期望删除以前关联的信息。
  • 对DELETE方法的响应不可缓存。如果删除请求通过具有一个或多个有效请求URI存储响应的缓存，则这些存储响应将无效

DELETE 方法具体见 RFC 7231 规范 - 第4.3.5节 。

6. CONNECT 方法 ​

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

  • CONNECT方法请求接收方建立到由请求目标标识的目标源服务器的隧道，如果成功，则随后将其行为限制为双向盲转发数据包，直到隧道关闭。隧道通常用于通过一个或多个代理创建端到端虚拟连接，然后可以使用TLS（传输层安全RFC5246）对其进行保护。

CONNECT 方法具体见 RFC 7231 规范 - 第4.3.6节 。

7. OPTIONS 方法 ​

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

  • OPTIONS方法请求有关目标资源可用的通信选项的信息，这些通信选项位于源服务器或中介。此方法允许客户机确定与资源或服务器功能相关的选项和/或需求，而无需执行资源操作。

OPTIONS 方法具体见 RFC 7231 规范 - 第4.3.7节 。

8. TRACE方法 ​

请求服务器回显客户端请求消息，主要用于测试或诊断。

  • TRACE方法请求请求消息的远程应用程序级循环。请求的最终接收者应将收到的消息（不包括下文所述的某些字段）作为内容类型为“消息/http”的200（确定）响应的消息正文反映回客户端。最后一个收件人是原始服务器或第一个在请求中接收最大转发值为零（0）的服务器。

TRACE 方法具体见 RFC 7231 规范 - 第4.3.8节 。

9. PATCH方法 ​

对资源进行部分修改。

  • PATCH方法请求将请求实体中描述的一组更改应用于由请求URI标识的资源。这组更改以一种称为“patch document”的格式表示，由媒体类型标识。如果请求URI未指向现有资源，服务器可能会创建新资源，具体取决于修补程序文档类型（是否可以逻辑修改空资源）和权限等。

  • PUT和PATCH请求之间的差异反映在服务器处理封闭实体以修改请求URI标识的资源的方式上。在PUT请求中，封闭的实体被视为存储在源服务器上的资源的修改版本，客户端请求替换存储的版本。然而，对于PATCH请求，封闭的实体包含一组说明，说明如何修改当前驻留在源服务器上的资源以生成新版本。PATCH方法会影响由请求URI标识的资源，并且可能会对其他资源产生副作用。

PATCH 方法具体见 RFC 5789 规范 - 第2节 。

10. MOVE 方法 ​

请求源服务器将目标资源 移动 到新的URI。

  • 非集合资源上的移动操作在逻辑上等同于复制（copy），然后是一致性维护处理，然后是源的删除，其中所有三个操作都在一个操作中执行。一致性维护步骤允许服务器执行由移动引起的更新，例如更新除标识源资源的请求URI之外的所有URL，以指向新的目标资源。

MOVE 方法具体见 WebDAV 规范 - 第9.9节 。

11. COPY 方法 ​

请求源服务器将目标资源 复制 到新的URI。

  • COPY方法在目标标头中由URI标识的目标资源中创建由请求URI标识的源资源的副本。目标标头必须存在。复制方法的确切行为取决于源资源的类型。
  • 所有符合WebDAV的资源都必须支持复制方法。但是，对复制方法的支持并不能保证复制资源的能力。例如，不同的程序可以控制同一服务器上的资源。因此，可能无法将资源复制到似乎位于同一服务器上的位置。

COPY 方法具体见 WebDAV 规范 - 第9.8节 。

12. LOCK 方法 ​

请求源服务器锁定目标资源。

  • 对现有资源的锁请求将在请求URI标识的资源上创建锁，前提是该资源尚未使用冲突锁锁定。请求URI中标识的资源将成为锁的根。创建新锁的锁方法请求必须具有XML请求主体。服务器必须在锁请求的“所有者”元素中保留客户端提供的信息。锁定请求可能有一个超时标头。

LOCK 方法具体见 WebDAV 规范 - 第9.10节 。

13. UNLOCK 方法 ​

请求源服务器解锁目标资源。

  • UNLOCK方法移除由锁令牌请求标头中的锁令牌标识的锁。请求URI必须标识锁范围内的资源。

UNLOCK 方法具体见 WebDAV 规范 - 第9.11节 。