什么是 HTTP？请求、响应、方法和 HTTPS

Scrapeless Web Unlocker 通过 API 获取公共网页内容，而由你的应用决定如何验证和处理每个结果。

HTTP 将资源请求与响应连接起来

HTTP 是超文本传输协议（Hypertext Transfer Protocol）的缩写，是一种应用层协议，被网页浏览器、API 和其他客户端用来交换资源的表示。客户端发送一个请求来标识资源和要执行的操作。服务器返回一个响应，其中包含状态、描述消息的字段，以及在操作需要时返回的内容。资源可以是一个 HTML 页面、一张图片，或结构化的应用数据。

这份 HTTP 语义标准 定义了跨协议版本共享的概念。URL 标识目标资源，方法描述请求的操作，字段承载有关请求或响应的信息。HTTP 并不要求每个资源都是磁盘上的文件。服务器可以从数据库生成一个表示、组合多个服务，或在返回内容之前应用访问规则。

一个网页通常涉及多次 HTTP 交互。初始 HTML 会引用样式表、脚本和图片，而页面的 JavaScript 可以请求额外数据。因此，读取第一个文档只回答了比渲染完成界面更窄的问题。在采集网页数据时，要识别究竟是哪一个响应或可见页面状态真正包含了任务所需的记录。

HTTP 请求包含什么

一个 HTTP 请求标识目标，并携带方法、请求字段和可选内容。人们熟悉的文本请求行属于 HTTP/1.1 的线路格式。更新的版本以不同方式对消息编码，但保留了共同的语义。检查工具通常以规范化形式展示这次交互，这对人类很方便，但不应被误认为是来自每个 HTTP 版本的原始字节。

请求字段可以描述可接受的媒体类型、首选语言、凭据，或对缓存表示的条件访问。请求体可以携带应用输入，例如提交的表单数据或一个 JSON 对象。方法和端点契约决定这些输入如何被解释。不要假定给任意方法添加内容就能形成可移植的 API 操作。

将资源的查询参数与消息字段和消息体数据区分开来。一个 API 可能把过滤条件和分页状态放在 URL 中，同时在消息体中接受更大的操作负载。参数名称、必需值和最大大小由该 API 自身的契约决定。HTTP 提供的是消息传输框架，它不会把每个应用的搜索、排序或记录选择行为标准化。

方法描述预期的操作

HTTP 方法传达请求的语义，应用程序应当一致地实现它们。GET 获取一个表示，HEAD 获取不含 GET 内容的响应信息，POST 请求目标处理提供的内容，PUT 在目标处创建或替换状态，DELETE 请求移除对目标的关联。具体的业务效果仍然属于应用本身。

安全方法被定义为从客户端视角基本是只读的，即便服务器仍然可以执行诸如日志记录之类的附带操作。幂等方法在相同请求被多次应用时应有相同的预期效果。这些是语义属性，而不是保证每个响应体都完全相同，或者保证配置错误的应用不会错误实现某个方法。

对于公共数据采集，应优先使用文档化的只读接口来提供所需信息。不要因为同一主机暴露了可读页面就推断出写操作的权限。采集方被授权的范围应描述它使用的资源和操作，包括站点是期望浏览器会话还是 API 凭据。

状态码需要结合消息体来解释

HTTP 状态码把响应归入某种结果类别。成功响应、重定向、客户端错误和服务器端错误传达的是不同信息，但状态码不会取代应用负载。一个响应在 HTTP 层面可能被视为成功，同时却包含业务错误或需要解释的空集合。在记录成功之前，要验证必需字段和预期记录。

网站也可以针对某个实际上没有页面的路由，在返回成功状态码的同时只返回一个通用的应用外壳。对于链接验证，要检查最终 URL、标题以及相关正文内容。跟随重定向是有用的，但重定向到首页并不能证明某个特定的产品页或文档页真实存在。预期的资源仍然必须在最终目的地实际存在。

保持错误分类精确。缺失资源、无效凭证、权限不足和达到配额上限是不同的结果。端点可能包含结构化的错误细节，用来说明发生的是哪一种情况。将脱敏后的证据与任务结果一并保存，如果未获得预期数据，要明确保留一个未完成状态。不要用一个外观上成功却为空的数据集替换失败的页面。

HTTPS 为传输增加了保护

HTTPS 在连接上使用带有 TLS 保护的 HTTP，帮助客户端验证服务器身份，并保护传输中的应用数据。资源模型仍然是 HTTP。加密连接依然可能承载无效输入、未授权操作或具有误导性的页面。安全性还取决于选择正确的源站、验证证书，以及执行应用自身的权限规则。

中间层会形成各自独立的保护边界。CDN 或反向代理可以在客户端这一侧终止 TLS，然后再与应用服务器建立另一条连接。某一段链路上捕获的诊断信息并不会自动描述所有链路。记录凭证被发送到哪里、在每个终止点是谁可以读取它，以及由哪个系统负责安全地转发请求。

HTTP 版本与 HTTPS 方案回答的是不同的问题。 HTTP/1.1 报文定界 描述的是一种特定的序列化方式，而 HTTP/2 多路复用 描述的是在同一套广义请求/响应模型之上的另一种映射。HTTP/3 使用 QUIC。诊断性能时要检查协商得到的协议，而不是从 URL 或浏览器页面的外观来猜测。

无状态性、Cookie 与应用会话

HTTP 的无状态语义意味着协议本身不要求服务器在请求之间记住对话。应用仍然可以通过 Cookie、授权凭证以及服务器端会话记录来维护状态。因此，用户的购物车或登录体验并不与 HTTP 的无状态模型相矛盾。状态由应用实现，并在连续的交互中被携带或引用。

Cookie 可以将请求与某个会话关联起来，但它的具体含义来自签发它的应用。不要在没有证据的情况下，仅凭一个陌生 Cookie 名称就赋予它安全用途。在诊断浏览器行为时，要区分“有 Cookie 存在”和“会话确实有效且已获授权”这两件事。即使浏览器仍保留存储的值，服务器也可以独立地使应用状态过期或撤销它。

“ HTTP Cookie 生命周期 ”是一个相关概念，而面向资源的 REST API 设计 则是在更广泛的架构风格中使用 HTTP。REST 与 HTTP 不是可以互换的术语。HTTP 是协议，而一个 API 可以使用 HTTP 而不满足 REST 架构关联的每一条约束。

缓存改变了响应来自哪里的方式

HTTP 缓存允许在缓存规则允许的情况下，用已存储的响应来满足请求。 HTTP 缓存标准 定义了新鲜度、验证机制以及决定何时允许重用的控制。因而，一个成功响应并不总是意味着源站为这一次请求生成了全新的内容。当任务需要在特定时间窗口内进行观测时，这一区别非常重要。

缓存策略同样用于保护数据边界。包含私有信息的响应可能需要与公共静态资源不同的处理方式。遵循源站的存储控制，并清晰地制定你自己的数据集新鲜度策略。同时记录获取时间和源站提供的时间戳（如果可用），可以帮助使用方理解某个采集值代表什么，而不会过度夸大其时效性。

应用级缓存与传输级缓存可以共存。即使 HTTP 响应已不再存在于网络缓存中，你的采集器仍可能重用已解析的记录。要单独定义这类重用。一个对昨日内容清单来说足够的新鲜的存储值，可能已经过旧，不适合当前的价格比较。缓存效率应当在减少不必要工作的同时，仍然满足任务声明的新鲜度要求。

在正确的采集工作流中使用 HTTP

当所需信息可以从返回的内容中获得，并且你的应用已经负责解析时，应使用 HTTP 内容获取工作流。 Scrapeless Web Unlocker 支持基于 URL 的内容获取和 Web Unlocker overview中描述的 JavaScript 渲染选项。应根据实际任务选择这些能力，而不是假定每个网站都需要完整的浏览器交互序列。

调用方接收到的 API 响应与目标网站的响应属于不同层次。某个数据服务可以报告它已经接受了一个任务，但目标内容依然需要检查。阅读已文档化的封装结构，检查相关的状态和内容字段，并运用记录级的接收标准。不要仅从外层 API 状态推断目标站点的响应。

查看 Scrapeless pricing 以匹配相应的计费模式，然后定义哪些 URL、表现形式和记录字段会让这次采集真正有用。一个站得住脚的结果会明确来源、观测边界以及被接受的内容。HTTP 知识帮助你定位正确的交互，而数据验证则判断该交互是否真正回答了业务问题。

结论

HTTP 提供了网页和 API 背后的资源和消息模型。一起阅读方法、字段、状态和内容，然后考虑加密、缓存和应用状态。对于采集工作，先确认哪个响应包含所需数据，并在宣告任务成功前核实记录本身。