このサイトの 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 エンドポイントへの 1 回の 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": []
}ただし、この方法には次の欠点があります。
- ファイアウォールルール側のクライアントは、Firewall Rules API と Filters API の両方で起こりうるすべての失敗に対して、エラー処理と例外処理を実装する必要があります。
- 他の Cloudflare 機能が使っているフィルターを誤って変更または削除しないよう、
PUTおよびDELETE操作は許可されません。
デフォルトでは、フィルターまたはルールのいずれかが無効な場合、どちらも作成されません。
ただし例外が 1 つあります。ルールの上限を超えそうな場合、Cloudflare はフィルターだけを作成し、ファイアウォールルールは作成しないことがあります。シーケンス図では、ルールはフィルターのあとに作成されるためです。
上限超過を解消したあと、またはゾーンで利用できない機能を要求していた問題を解消したあと、推奨フローに戻り、そのフィルターを参照するルールを作成します。
まとめると、Cloudflare は 2 回の API 呼び出しによるシーケンスを強く推奨します。簡易シーケンスでのルールとフィルター作成は緊急時に限り、curl リクエストのみで行ってください。