← 全部文章
产品动态 2 分钟阅读

Validate 规则现已决定何为成功

使用 validate 规则声明哪些 response 属于成功。您接受的非 200 response 现在将正确计费，并在您的 Activity 动态中显示为成功。

apivalidationoutcomesbilling

您 request 中的 validate 规则现已用于决定每个结果的分类方式。将 403 声明为可接受状态后，返回的 403 将计为成功、按成功计费，并与 200 响应一同显示在 Activity 动态中。

这看似微小，却改变了您在大规模场景下衡量抓取准确率的方式。

工作原理

发送至 FourA 的每个 request 都会归为七种结果之一，用以确定计费和分析数据。只有 success 会计费。其余结果按失败责任方划分：

  • application_fail 和 application_error：目标站点拒绝连接或返回错误 body
  • client_error：您发送的 request 格式错误
  • service_fail、service_error 和 rate_limit：我们平台侧拦截了该 request

在此项变更之前，成功仅代表一种情况：HTTP 200。403 始终会被标记为 application_fail，即使您明确知道 403 正是您需要的 response。（某些体育数据 API 会对受地理限制的市场返回 403，而这正是您代码所等待的信号。）

现在由您的 validate 配置块决定。request 在执行期间会运行您的规则。如果 response 满足这些规则，结果即为 success。

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/api/feed",
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 403] },
      "data": { "fail": ["captcha", "Access Denied"] }
    }
  }'

这会将 200 和 403 均视为有效状态码。如果响应体包含验证页面标记或访问被拒绝的字符串，则 request 失败。其他情况均为 success。

需要记住的两条规则：

  1. 没有 validate 时，行为保持不变。 未声明校验的 request 仍仅对 HTTP 200 计费。完全由你主动选择启用。
  2. validate 双向生效。 Accept 规则放行，fail 规则拒绝。它们可以组合使用。因此你可以接受 [200, 403]，但当响应体包含错误内容时仍判定为失败。

影响

此项改动对那些目标网站返回非 200 响应但实际需要这些数据的团队最为关键。

我们日常看到的 request 示例：

  • 体育数据 API 对受地理限制的市场返回 403（仍然是有用的数据，仍然值得记录为成功）
  • 电商搜索 endpoint 在 SKU 缺货时返回 404（这是代码可读取的信号，而非错误）
  • 返回 206 的流媒体和部分内容 API

在改动之前，这些团队必须在我们的 Activity 日志之上自行记账。他们无法信任 outcome 列，因为他们对成功的定义与我们不一致。他们需要为自己并不真正关心的数字买单。

现在该列反映了实际情况。控制台中的 Activity 标签页显示的是你定义的成功，而不是我们的猜测。你的计费总额与你自行统计的结果一致（早期结果：该改动仅向后生效，因此旧的 Activity 记录保留其原始分类）。

对抓取任务的实际影响：减少了数据管道与我们账单之间的对账步骤。如果你之前已经在事后对 response body 进行校验，现在可以将该契约直接移入 request 本身，无需在我们的 API 之外维护一套并行的通过/失败规则。用一套唯一定义来判断 request 是否有效并进入数据集，而不是两套产生冲突的规则。

但我们保留了兜底保障。如果你没有传递 validate 块，一切都不会改变。分类器会回退到“200 即成功”，因此昨天能正常工作的 request 今天仍以相同方式运行。

进阶用法

validate 接受三套独立运行的规则集：status、headers 和 data。每套规则集都可以接收可选的 accept 和 fail 列表。

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/product/9876",
    "followRedirects": 5,
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 304] },
      "headers": { "accept": { "content-type": "application/json" } },
      "data": { "accept": ["\"price\":"], "fail": ["maintenance", "captcha"] }
    }
  }'

这需要满足：

  • 状态码为 200 或 304
  • Response 声明了 JSON 内容类型
  • Body 包含 price 字段
  • Body 不包含维护通知或验证页面

如果任何规则未通过，结果即为 application_fail。如果全部通过，则为 success。分类器在 request 内部运行，因此省去了单独验证步骤带来的网络往返开销。

配合 followRedirects 使用：最多跟踪 5 次跳转，然后验证最终的 response。从干净的 URL 跳转到验证页面的诱导重定向会直接明确失败，而不会污染你的数据集。

来自我们自身运行爬虫的一点经验：尽可能严格地声明 data.fail 模式。返回 200 OK 但内容是验证页面，是受保护站点上最常见的静默失败模式。请以 body 为准，而不是状态码。

关于完整 schema，request reference 列出了每个 validate 字段及其组合方式。

下一步计划

我们正在开发更丰富的规则原语：针对 data 的正则匹配器、结构化 JSON-path 谓词以及更灵活的 header 匹配。核心原则保持不变。你定义成功的标准，API 端到端严格执行，从发起 request 一直到计费账单。

当爬虫失效时，应该直接报错告警。而当它按照你自己编写的规则正常运行时，产生的数据指标才真正值得信赖。