Validateルールが成功の判定基準に

リクエストのvalidateルールが、すべての結果の分類方法を制御するようになりました。403を許容すると宣言すれば、配信された403は成功としてカウントされ、成功として課金され、200とともにActivityフィードに記録されます。

これは些細なことのように聞こえるかもしれません。しかし、大規模なスクレイピングの精度の測定方法を変えるものです。

仕組み

FourAへのすべてのリクエストは、課金と分析を決定する7つの結果のいずれかを受け取ります。successのみが課金対象です。残りは失敗の原因によって分類されます。

ターゲットサイトが拒否した、またはエラーボディを返した場合はapplication_failおよびapplication_error
送信したリクエストの形式が正しくない場合はclient_error
当社側でリクエストがブロックされた場合はservice_fail、service_error、およびrate_limit

この変更前は、成功が意味するものはHTTP 200の1つだけでした。その403が求めるレスポンスであるとわかっていても、403は常にapplication_failでした。(一部のスポーツデータAPIはジオフェンスされた市場に対して403を返し、それがコードの待機しているシグナルになります。)

これからはvalidateブロックが決定します。リクエストは実行時にルールを実行します。レスポンスがそれらを満たす場合、結果は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を有効なステータスコードとして扱います。ボディにCAPTCHAマーカーやアクセス拒否の文字列が含まれている場合、リクエストは失敗します。それ以外はすべてsuccessです。

覚えておくべき2つのルールがあります。

validateがない場合、動作は変わりません。 validationを宣言しないリクエストは、引き続きHTTP 200の場合のみ課金されます。オプトイン方式です。
validateは両方向に機能します。 acceptルールは通過し、failルールは拒否します。これらは組み合わされます。そのため、[200, 403]を許容しつつ、ボディに誤ったコンテンツが含まれている場合は失敗させることができます。

影響

この変更は、ターゲットが実際に必要とする200以外のレスポンスを返すチームにとって最も重要です。

私たちが日常的に目にするリクエストの例を挙げます。

ジオフェンスされた市場に対して403を返すスポーツデータAPI(依然として有用なデータであり、成功として記録する価値があります)
SKUが在庫切れのときに404を返すEコマース検索エンドポイント(コードが読み取るシグナルであり、失敗ではありません)
206を返すストリーミングおよび部分コンテンツAPI

変更前は、これらのチームは私たちのActivityログの上で独自の帳簿管理を行っていました。彼らの成功の定義と私たちの定義が一致していなかったため、outcome列を信頼できませんでした。彼らは実際には気にしていない数字に対して課金されていました。

現在、この列は現実を反映しています。DashboardのActivityタブには、私たちが推測したものではなく、あなたが定義した成功が表示されます。課金される合計は、あなたが自分でカウントするものと一致します(初期の結果: 変更は前方にのみ適用されたため、古いActivity行は元の分類を保持します)。

スクレイピングジョブにおける実際の影響は、パイプラインと当社の請求書間の照合手順が減ることです。事後にレスポンスボディでvalidationを実行していた場合は、そのコントラクトをリクエスト自体に移動し、APIの外部で合否ルールの並行セットを維持するのをやめることができます。リクエストがデータセットに含まれるべきかどうかの定義が、矛盾する2つではなく1つになります。

しかし、セーフティネットは維持しています。validateブロックを渡さない場合、何も変わりません。分類器は「200が成功を意味する」にフォールバックするため、昨日機能していたリクエストは今日も同じように機能します。

パワーユーザー向け

validateは、独立して実行される3つのルールセット(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
レスポンスがJSONコンテンツタイプをアドバタイズする
ボディにpriceフィールドが含まれている
ボディにメンテナンス通知やCAPTCHAトラップが含まれていない

いずれかのルールが失敗した場合、結果はapplication_failになります。すべてが通過した場合はsuccessです。分類器はリクエスト自体の中で実行されるため、個別のvalidationステップにかかるラウンドトリップを省略できます。

followRedirectsとの組み合わせ。最大5ホップまで追跡し、最終レスポンスをvalidateします。クリーンなURLからCAPTCHAゲートへのおとり商法は、データセットを汚染するのではなく、きれいに失敗します。

私たち自身のスクレイパーを実行した経験からのヒント。data.failパターンを積極的に宣言してください。内部にCAPTCHAが含まれる200 OKは、保護されたサイトで最も一般的なサイレント障害モードです。ステータスコードではなく、ボディを信頼できるものとして扱います。

完全なスキーマについては、リクエストリファレンスにすべてのvalidateフィールドとそれぞれの構成方法が記載されています。

次のステップ

より豊富なルールプリミティブの開発を進めています。dataの正規表現マッチャー、構造化されたJSON-path述語、より緩やかなヘッダーマッチングなどです。原則は変わりません。あなたが成功の形を宣言し、APIはリクエストから請求書まで、エンドツーエンドでそれを尊重します。

スクレイパーが壊れたときは、それをはっきりと知らせるべきです。そして、自分で書いたルールに従って動作したとき、それは実際に信頼できる数字になります。