2、HTTP请求方法：从GET到DELETE，数据采集的“武器库”
各位好，我是老周。今天咱们聊聊HTTP请求方法。说白了，这就是你跟服务器打交道的几种“手势”。你用什么手势，服务器就知道你想干嘛——是拿数据、交数据、改数据，还是删数据。
我刚开始做采集那会儿，就只会用GET。后来发现，很多场景用对方法，效率能翻倍。咱们一个一个来看。
2.1 GET方法：数据采集的“主力军”
GET，顾名思义，就是“获取”。你向服务器要资源，服务器把资源给你。这是数据采集里用得最多的方法，没有之一。
核心特点：GET请求的参数都挂在URL后面，比如 https://api.example.com/users?id=123。服务器看到这个请求，就知道你要查ID为123的用户。
我个人的习惯是，只要目标是“读数据”，优先用GET。为什么？因为它简单、可缓存、还能被浏览器直接收藏。你想想看，爬虫抓取新闻列表、商品详情，哪个不是GET？
GET的“坑”与避坑
- URL长度限制：不同浏览器和服务器对URL长度有限制，一般是2048个字符左右。如果你要传大量参数（比如一个很长的搜索关键词），GET可能就不合适了。
- 敏感数据别用GET：参数明文暴露在URL里，会被浏览器历史、服务器日志记录下来。我见过有人把密码写在GET参数里……嗯，这是大忌。
- 幂等性：同一个GET请求发100次，结果应该是一样的。服务器不会因为你多刷几次就多扣你钱。这是GET的天然属性。
采集小技巧：很多网站的分页参数就是GET方式。比如 ?page=1、?page=2。你只需要循环改变page的值，就能拿到所有数据。我曾经用这个办法，半小时抓完了一个电商网站的全部商品列表。
2.2 POST方法：表单提交与数据“投递”
POST跟GET不一样。它不是去“拿”，而是去“交”。你把数据放在请求体（Request Body）里发给服务器，服务器处理完后给你一个结果。
举个例子：你登录一个网站，填好用户名和密码，点“登录”。这时候浏览器发出去的就是一个POST请求。用户名和密码藏在请求体里，不会暴露在URL上。
POST在数据采集中的应用
很多人以为采集就是发GET请求。其实很多数据藏在POST请求里。比如：
- 模拟登录：先发一个POST提交登录表单，拿到Cookie，再用这个Cookie去请求需要登录才能看到的页面。
- 搜索接口：很多网站的搜索功能是用POST的，因为搜索条件可能很复杂（关键词、分类、价格区间……），放在URL里太长，放在请求体里更合适。
- 文件上传：如果你要采集需要上传文件才能触发的数据，那必须用POST。
注意：POST请求不是幂等的。你发两次POST，服务器可能会创建两条记录。比如你提交了两次订单，可能会下两个单。所以采集时，如果涉及到“提交”操作，一定要小心重复提交的问题。
2.3 PUT与DELETE：增删改查的“改”和“删”
这两个方法在RESTful API里很常见。说白了，PUT用来“更新”或“创建”资源，DELETE用来“删除”资源。
| 方法 | 作用 | 幂等性 | 数据采集场景 |
|---|---|---|---|
| PUT | 更新或替换一个资源 | 是（幂等） | 更新采集到的数据状态（比如标记已处理） |
| DELETE | 删除一个资源 | 是（幂等） | 清理测试数据、删除无效记录 |
我举个例子。假设你采集了一个用户列表，发现某个用户数据有误，需要更新。这时候你可以发一个PUT请求，把正确的数据传过去。如果你发现某个用户已经不存在了，可以发DELETE请求把它从你的本地数据库里删掉。
避坑指南：我曾经在采集一个内部系统时，不小心用GET请求调用了DELETE接口。结果……嗯，你懂的。从那以后，我每次发请求前都会再三确认方法。记住：GET永远不要用来做“写”操作。
2.4 HEAD与OPTIONS：低调的“侦察兵”
这两个方法平时用得少，但在数据采集里，它们能帮你省不少事。
HEAD：只拿“头”，不拿“身”
HEAD和GET几乎一样，唯一的区别是：服务器只返回响应头（Response Headers），不返回响应体。有什么用？
- 检查资源是否存在：发一个HEAD请求，如果返回200，说明资源存在；如果返回404，说明不存在。不用下载整个页面，省流量、省时间。
- 获取文件大小：响应头里的
Content-Length字段会告诉你文件有多大。你可以根据这个决定要不要下载。 - 检查最后修改时间：响应头里的
Last-Modified字段可以告诉你资源是否更新过。如果没更新，就不用重新抓取了。
我的经验：在采集大量图片或文件时，我会先用HEAD请求检查文件大小和类型。如果文件太大或者格式不对，直接跳过，不浪费带宽。这个小技巧帮我省了不少服务器资源。
OPTIONS：看看服务器“支持什么”
OPTIONS方法用来询问服务器：这个接口支持哪些请求方法？支持哪些请求头？
比如你发一个OPTIONS请求到 https://api.example.com/users，服务器可能会返回：
Allow: GET, POST, PUT, DELETE, OPTIONS这就告诉你，这个接口支持这些方法。如果你发了一个PATCH请求，服务器可能会返回405（Method Not Allowed）。
在数据采集里，OPTIONS可以用来“探路”。特别是遇到一些不熟悉的API时，先发个OPTIONS看看它支持什么，心里就有底了。
2.5 安全性与幂等性：两个容易被忽略的概念
这两个概念很重要，我单独拿出来说。
安全性（Safe）
一个方法是“安全”的，意味着它不会改变服务器上的资源。说白了，就是“只读”的。GET、HEAD、OPTIONS都是安全的。POST、PUT、DELETE不是安全的，因为它们会修改或删除数据。
为什么要在意这个？因为爬虫和搜索引擎会“预取”一些链接。如果这些链接用的是不安全的方法，可能会造成数据污染。比如搜索引擎预取了一个DELETE链接，那你的数据可能就被删了。
幂等性（Idempotent）
一个方法是“幂等”的，意味着你发一次和发一百次，结果是一样的。GET、PUT、DELETE都是幂等的。POST不是幂等的。
举个例子：你发一个DELETE请求删除ID为123的用户。第一次发，用户被删了。第二次再发，用户已经不存在了，服务器返回404。但服务器的状态是一样的——用户不存在。所以DELETE是幂等的。
但POST不一样。你发一次POST创建用户，服务器创建了一个。再发一次，又创建了一个。结果不一样，所以POST不是幂等的。
| 方法 | 安全 | 幂等 | 说明 |
|---|---|---|---|
| GET | 是 | 是 | 只读，不改变资源 |
| HEAD | 是 | 是 | 只读，不返回响应体 |
| OPTIONS | 是 | 是 | 只读，查询接口能力 |
| POST | 否 | 否 | 创建资源，不幂等 |
| PUT | 否 | 是 | 更新/替换资源，幂等 |
| DELETE | 否 | 是 | 删除资源，幂等 |
重要提醒：在编写采集脚本时，一定要搞清楚目标接口的安全性和幂等性。我曾经见过一个新手，用GET请求去调用一个删除接口，结果把整个测试库清空了。还好是测试环境……从那以后，我写采集脚本的第一件事就是确认接口文档。
本章知识体系
下面这张图，帮你理清这六种方法的关系和适用场景。
好了，这一章的内容就到这里。六种方法，各有各的脾气。GET和POST是主力，PUT和DELETE是辅助，HEAD和OPTIONS是侦察兵。记住它们的安全性和幂等性，写采集脚本的时候就能少踩坑。