调用顺序

本网站中的 API 调用示例说明了调用这两个 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 操作。

默认情况下，如果过滤器或规则无效，则两者都不会被创建。

但是，存在一个例外。如果您即将超过您的规则配额，Cloudflare 可能会创建过滤器但不创建防火墙规则。这是因为规则在顺序图中是在过滤器之后才创建的。

在您解决了超出配额或请求区域不可用的功能的问题后，请返回推荐流程以创建引用该过滤器的规则。

总之，Cloudflare 强烈推荐具有两次 API 调用的顺序。将使用简化顺序创建规则和过滤器限制在紧急情况下，并且仅通过 curl 请求进行。