呼び出しシーケンス
このサイトのAPI呼び出しの例は、2つのAPI(Cloudflare Filters APIとFirewall Rules API)を呼び出す推奨シーケンスを示しています。
以下の画像は、このシーケンスを示しており、ルールの作成と編集に適用できます。削除操作には逆のシーケンスが適用されます。

Cloudflareはこのシーケンスを推奨しています。なぜなら、フィルターの再利用を促進し、どちらのAPIも独立して操作できるからです。Cloudflare Filtersの独立した性質のおかげで、同じフィルターを複数のファイアウォールルールや将来のCloudflare製品および機能で共有できます。
例えば、APIのすべてのトラフィックに一致するフィルター(つまり、http.request.uri.path matches "^/api/.*$")は、キャッシュを無効にし、人間のCAPTCHAを無効にし、JSONカスタムエラーを設定し、ファイアウォールルールに表示されることがあります。上記の推奨シーケンスに従うと、ステップ1-2で作成した同じフィルターに対して、すべてのCloudflare機能を設定するためにステップ3-6を繰り返すことになります。
ただし、POST操作の場合、以下に示す簡略化されたシーケンスを使用すると、同じ呼び出しでフィルターとルールの両方を作成できます。この場合、フィルターとルールは互いに参照し合います。

このシーケンスでは、/firewall/rulesエンドポイントへの単一のPOSTリクエストが、フィルターオブジェクトをJSONで受け取り、Filters APIでフィルターを作成します(これもPOSTリクエストを介して)。成功した場合、ファイアウォールルールが作成されます。
以下は、この方法を使用した呼び出しと応答の例です:
curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/firewall/rules" \--header "X-Auth-Email: <EMAIL>" \--header "X-Auth-Key: <API_KEY>" \--header "Content-Type: application/json" \--data '[ { "filter": { "expression": "http.request.uri.path contains \"/api/\" and ip.src eq 93.184.216.34" }, "action": "block" }]'{ "result": [ { "id": "<RULE_ID>", "paused": false, "action": "block", "priority": null, "filter": { "id": "<FILTER_ID>", "expression": "http.request.uri.path contains \"/api/\" and ip.src eq 93.184.216.34", "paused": false } } ], "success": true, "errors": [], "messages": []}ただし、このアプローチにはいくつかの欠点があります:
- ファイアウォールルールクライアントは、ファイアウォールルールとフィルターAPIの両方で発生する可能性のあるすべての失敗に対してエラーおよび例外処理を実装する必要があります。
- 他のCloudflare機能で使用されるフィルターを誤って変更または削除しないようにするために、
PUTまたはDELETE操作は許可されていません。
デフォルトでは、フィルターまたはルールのいずれかが無効な場合、どちらも作成されません。
ただし、1つの例外があります。ルールのクォータを超えようとしている場合、Cloudflareはフィルターを作成することはできますが、ファイアウォールルールは作成しません。これは、シーケンス図でフィルターの後にルールが作成されるためです。
クォータを超える問題を解決するか、ゾーンで利用できない機能をリクエストした後は、フィルターを参照するルールを作成するために推奨フローに戻ってください。
要約すると、Cloudflareは2つのAPI呼び出しを伴うシーケンスを強く推奨しています。緊急時には簡略化されたシーケンスを使用してルールとフィルターの作成を制限し、curlリクエストを介してのみ行ってください。