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

Validate 规则现已决定何为成功

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

apivalidationoutcomesbilling

您的 request 的 validate 规则现在决定了每个 outcome 的分类方式。将 403 声明为可接受，那么成功交付的 403 就会被视为成功、按成功计费，并与您的 200 一起显示在 Activity 动态中。

这听起来微不足道，但它改变了您在大规模抓取时衡量准确率的方式。

工作原理

发送给 FourA 的每个 request 都会获得七种 outcome 之一，用以决定计费和分析。只有 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 满足这些规则，则 outcome 为 success。

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "Authorization: Bearer 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 视为有效的状态码。如果 body 包含 CAPTCHA 标记或拒绝访问字符串，则 request 失败。其他任何情况均为 success。

需要记住的两条规则：

  1. 没有 validate 时，行为保持不变。 未声明验证的 request 仍仅针对 HTTP 200 计费。您需要主动选择启用。
  2. validate 双向运行。 接受规则通过，失败规则拒绝。它们可以组合使用。因此，您可以接受 [200, 403]，但在 body 包含错误内容时仍然判定为失败。

影响

这一转变对于那些目标网站会返回其真正需要的非 200 response 的团队来说最为重要。

我们每天看到的 request 示例：

  • 针对地理限制市场返回 403 的体育数据 API（这仍然是有用的数据，仍然值得记录为成功）
  • 当 SKU 无货时返回 404 的电子商务搜索 endpoint（这是您的代码读取的信号，而不是失败）
  • 返回 206 的流媒体和部分内容 API

在更改之前，这些团队需要在我们的 Activity 日志之上运行自己的记账逻辑。他们无法信任 outcome 列，因为他们对成功的定义与我们的不一致。他们被按一个他们实际上并不关心的数字计费。

现在，该列反映了真实情况。您 Dashboard 中的 Activity 标签页会显示您定义的成功，而不是我们猜测的结果。您的计费总额与您自己统计的相符（早期结果：此更改仅向前滚动，因此旧的 Activity 行保留其原始分类）。

对抓取任务的实际效果：减少了您的 pipeline 与我们账单之间的对账步骤。如果您之前已经在事后对 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 "Authorization: Bearer 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 不包含维护通知或 captcha 陷阱

如果任何规则失败，outcome 即为 application_fail。如果全部通过，则为 success。分类器在 request 内部运行，因此您无需承担单独验证步骤所带来的往返延迟。

结合 followRedirects：最多追踪五次跳转，然后验证最终的 response。从干净的 URL 诱骗跳转到 CAPTCHA 拦截页的情况将会干净利落地失败，而不会污染您的数据集。

来自我们运行自己爬虫的一个建议：积极地声明 data.fail 模式。在受保护的网站上，包含 CAPTCHA 的 200 OK 是最常见的隐性失败模式。请将 body 视为权威依据，而不是状态码。

有关完整 schema，request 参考列出了每个 validate 字段以及它们是如何组合的。

下一步计划

我们正在开发更丰富的规则原语：用于 data 的正则表达式匹配器、结构化的 JSON-path 断言以及更宽松的 header 匹配。原则保持不变：您声明成功的标准，API 端到端地执行它，从 request 一直到您的账单。

当您的爬虫崩溃时，它应该明确地报错。而当它按照您自己编写的规则正常运行时，那才是一个您真正可以信任的数字。