【学习笔记】透视HTTP协议（八）：请求方法详解

叶阿猪

于 2024-06-14 23:24:18 发布

阅读量1.6k

点赞数 38

分类专栏：接口测试计算机网络 HTTP 文章标签： http 计算机网络

本文链接：https://blog.csdn.net/MAOZI8/article/details/139652122

版权

HTTP 同时被 3 个专栏收录

18 篇文章 0 订阅

订阅专栏

接口测试

10 篇文章 0 订阅

订阅专栏

计算机网络

8 篇文章 0 订阅

订阅专栏

本文是一篇学习笔记，学习的课程是极客时间的《透视HTTP协议》。

透视HTTP协议_HTTP_HTTPS-极客时间 (geekbang.org)

HTTP的请求方法（也称为HTTP动词或HTTP方法）定义了客户端如何与服务器进行交互。HTTP协议为这些请求方法提供了一套标准的语义，以便客户端可以明确地告诉服务器它想要执行的操作。

以下是HTTP/1.1规范中定义的几种主要的请求方法及其用途。

一、标准请求方法

HTTP协议里为什么要有“请求方法”这个东西呢？

蒂姆·伯纳斯-李最初设想的是要用HTTP协议构建一个超链接文档系统，使用URI来定位这些文档，也就是资源。那么，该怎么在协议里操作这些资源呢？

很显然，需要有某种“动作的指示”，告诉操作这些资源的方式。所以，就这么出现了“请求方法”。它的实际含义就是客户端发出了一个“动作指令”，要求服务器端对URI定位的资源执行这个动作。

目前HTTP/1.1规定了八种方法，单词都必须是大写的形式

GET：获取资源，可以理解为读取或者下载数据；
HEAD：获取资源的元信息；
POST：向资源提交数据，相当于写入或上传数据；
PUT：类似POST；
DELETE：删除资源；
CONNECT：建立特殊的连接隧道；
OPTIONS：列出可对资源实行的方法；
TRACE：追踪请求-响应的传输路径。
TRACE：追踪请求-响应的传输路径。

这些方法有点像对文件或数据库的“增删改查”操作，只不过这些动作操作的目标不是本地资源，而是远程服务器上的资源，所以只能由客户端“请求”或者“指示”服务器来完成。

既然请求方法是一个“指示”，那么客户端自然就没有决定权，服务器掌控着所有资源，也就有绝对的决策权力。它收到HTTP请求报文后，看到里面的请求方法，可以执行也可以拒绝，或者改变动作的含义，毕竟HTTP是一个“协议”，两边都要“商量着来”。

比如，你发起了一个GET请求，想获取“/orders”这个文件，但这个文件保密级别比较高，不是谁都能看的，服务器就可以有如下的几种响应方式：

假装这个文件不存在，直接返回一个404 Not found报文；
稍微友好一点，明确告诉你有这个文件，但不允许访问，返回一个403 Forbidden；
再宽松一些，返回405 Method Not Allowed，然后用Allow头告诉你可以用HEAD方法获取文件的元信息。

二、GET/HEAD

它的含义是请求从服务器获取资源，这个资源既可以是静态的文本、页面、图片、视频，也可以是由PHP、Java动态生成的页面或者其他格式的数据。

GET方法虽然基本动作比较简单，但搭配URI和其他头字段就能实现对资源更精细的操作。

在URI后使用“#”，就可以在获取页面后直接定位到某个标签所在的位置；
使用If-Modified-Since字段就变成了“有条件的请求”，仅当资源被修改时才会执行获取动作；
使用Range字段就是“范围请求”，只获取资源的一部分数据。

HEAD方法与GET方法类似，也是请求从服务器获取资源，服务器的处理机制也是一样的，但服务器不会返回请求的实体数据，只会传回响应头，也就是资源的“元信息”。

想要检查一个文件是否存在，只要发个HEAD请求就可以了，没有必要用GET把整个文件都取下来。
要检查文件是否有最新版本，同样也应该用HEAD，服务器会在响应头里把文件的修改时间传回来。

三、POST/PUT

GET和HEAD方法是从服务器获取数据，而POST和PUT方法则是相反操作，向URI指定的资源提交数据，数据就放在报文的body里。

比如，你上论坛灌水，敲了一堆字后点击“发帖”按钮，浏览器就执行了一次POST请求，把你的文字放进报文的body里，然后拼好POST请求头，通过TCP协议发给服务器。

PUT的作用与POST类似，也可以向服务器提交数据，但与POST存在微妙的不同，通常POST表示的是“新建”“create”的含义，而PUT则是“修改”“update”的含义。

在实际应用中，PUT用到的比较少。而且，因为它与POST的语义、功能太过近似，有的服务器甚至就直接禁止使用PUT方法，只用POST方法上传数据。

四、其他方法

DELETE方法指示服务器删除资源，因为这个动作危险性太大，所以通常服务器不会执行真正的删除操作，而是对资源做一个删除标记。当然，更多的时候服务器就直接不处理DELETE请求。

CONNECT是一个比较特殊的方法，要求服务器为客户端和另一台远程服务器建立一条特殊的连接隧道，这时Web服务器在中间充当了代理的角色。

OPTIONS方法要求服务器列出可对资源实行的操作方法，在响应头的Allow字段里返回。它的功能很有限，用处也不大，有的服务器（例如Nginx）干脆就没有实现对它的支持。

TRACE方法多用于对HTTP链路的测试或诊断，可以显示出请求-响应的传输路径。它的本意是好的，但存在漏洞，会泄漏网站的信息，所以Web服务器通常也是禁止使用。

五、扩展方法

虽然HTTP/1.1里规定了八种请求方法，但它并没有限制我们只能用这八种方法，这也体现了HTTP协议良好的扩展性，我们可以任意添加请求动作，只要请求方和响应方都能理解就行。

此外，还有一些得到了实际应用的请求方法（WebDAV），例如MKCOL、COPY、MOVE、LOCK、UNLOCK、PATCH等。如果有合适的场景，你也可以把它们应用到自己的系统里，比如用LOCK方法锁定资源暂时不允许修改，或者使用PATCH方法给资源打个小补丁，部分更新数据。但因为这些方法是非标准的，所以需要为客户端和服务器编写额外的代码才能添加支持。

六、安全与幂等

关于请求方法还有两个面试时有可能会问到、比较重要的概念：安全与幂等。

在HTTP协议里，所谓的“安全”是指请求方法不会“破坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。

按照这个定义，只有GET和HEAD方法是“安全”的，因为它们是“只读”操作，只要服务器不故意曲解请求方法的处理方式，无论GET和HEAD操作多少次，服务器上的数据都是“安全的”。

而POST/PUT/DELETE操作会修改服务器上的资源，增加或删除数据，所以是“不安全”的。

所谓的“幂等”实际上是一个数学用语，被借用到了HTTP协议里，意思是多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”。

很显然，GET和HEAD既是安全的也是幂等的，DELETE可以多次删除同一个资源，效果都是“资源不存在”，所以也是幂等的。

POST和PUT的幂等性质就略费解一点。

按照RFC里的语义，POST是“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等的；而PUT是“替换或更新数据”，多次更新一个资源，资源还是会第一次更新的状态，所以是幂等的。

可以对比一下SQL来加深理解：把POST理解成INSERT，把PUT理解成UPDATE，这样就很清楚了。多次INSERT会添加多条记录，而多次UPDATE只操作一条记录，而且效果相同。

七、小结

请求方法是客户端发出的、要求服务器执行的、对资源的一种操作；
请求方法是对服务器的“指示”，真正应如何处理由服务器来决定；
最常用的请求方法是GET和POST，分别是获取数据和发送数据；
HEAD方法是轻量级的GET，用来获取资源的元信息；
PUT基本上是POST的同义词，多用于更新数据；
“安全”与“幂等”是描述请求方法的两个重要属性，具有理论指导意义，可以帮助我们设计系统。

题外话：TRACE、OPTIONS和CONNECT方法，能不能用GET或POST方法间接实现？

不能，原因如下：

TRACE：此方法用于诊断，它会回显服务器收到的请求，主要用于测试或诊断。它并不涉及资源的获取或修改，因此不能用GET或POST替代。
OPTIONS：此方法用于描述通信选项供目标资源。它用于检查服务器的性能，并不涉及实际的数据传输或处理，所以也不能用GET或POST来模拟。
CONNECT：此方法用于HTTP代理，允许双向的HTTP隧道。它通常用于SSL加密服务器的链接（经由非加密的HTTP代理）。这种方法的特殊性使其无法被GET或POST方法所替代。

题外话：把GET/POST等请求方法对应到数据库的“增删改查”操作吗？请求头应该如何设计呢？

GET：通常对应于数据库的“查”（Read）操作。使用GET请求时，我们通常是从服务器检索信息，比如从数据库中读取数据。

POST：可以对应于数据库的“增”（Create）操作。使用POST请求时，我们通常是在向服务器提交数据，比如向数据库中添加新的记录。但请注意，POST也可以用于更新数据（即“改”操作）。

PUT/PATCH：对应于数据库的“改”（Update）操作。PUT请求用于更新资源，而PATCH请求用于对资源进行部分更新。在数据库中，这相当于更新已有记录的信息。

DELETE：直接对应于数据库的“删”（Delete）操作。使用DELETE请求时，我们请求服务器删除某个资源，这类似于从数据库中删除记录。