Cato APIのレート制限は、クエリーごと、アカウントごとに適用されます。 これは、各クエリーに個別のカウンターがあることを意味しますが、そのアカウントをクエリーするすべてのAPIキー（異なるユーザー用）に適用されます。 したがって、2人の異なるユーザーが別々のクエリーを呼び出しても、お互いに影響を与えることはありません。 しかし、2人の異なるユーザーが同じクエリーを呼び出す場合、これらのクエリーは同じカウンターの対象となり（レート制限の目的で）、1人のユーザーのクエリーが他のユーザーに影響を与える可能性があります。
Cato APIのバックエンドは非常に可用で弾力性があるため、レート制限は絶対的な最大ではなく保証された最小値です。 たとえば、auditFeedクエリーには1分あたり5回のレート制限があります。これは、アカウントがレート制限されることなく、60秒ごとに少なくとも5回はauditFeedを呼び出せることを意味します。 実際には、顧客がこのクエリーをもっと頻繁に呼び出すことができますが、無制限の呼び出しの保証された最小レートは1分あたり5回です。 それでも、アカウント全体でカウンターがあるため、5人の異なるユーザーが同時にauditFeedをクエリーする場合、レート制限の影響を受けないことを保証するために、各ユーザーは60秒ごとにクエリーを1回しか呼び出せません。
CatoのGithubアカウントには、5秒待ってから再試行することでレート制限を優雅に処理するサンプルのPythonスクリプトが含まれています。 顧客は、自分のAPIスクリプトで同様の戦略を採用することができます。
クエリーがレート制限に関連する問題に遭遇した場合、数分待ってから追加のAPIクエリーを再開することをお勧めします。
API呼び出しは、次のクエリーおよびミューテーションを除いて、1分あたり120回のレート制限があります。
以下のクエリーAPIは例外であり、1分あたり120回のレート制限がありません。
-
accountMetrics: 1分あたり15回
-
accountSnapshot: 1秒あたり1回（1分あたり30回）
-
appStatsTimeSeries: 1分あたり80回
-
auditFeed: 1分あたり5回
-
entityLookup: 1分あたり30回（5時間あたり1500回）
-
eventsFeed: 1分あたり100回
以下のミューテーションAPIは例外であり、1分あたり120回のレート制限がありません。
-
accountManagement.addAccount: 1分あたり10回
-
accountManagement.removeAccount: 1分あたり5回
-
policy.appTenantRestriction.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
policy.dynamicIpAllocation.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
policy.internetFirewall.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
policy.pacFile.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
policy.remotePortFwd.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
policy.socketLanFirewall.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
policy.socketLanNetwork.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
policy.wanFirewall.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
policy.wanNetwork.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
policy.ztnaAlwaysOn.publishPolicyRevision: 1分あたり3回（1時間あたり20回）
-
sandbox.uploadFile: 5分ごとに5回
0件のコメント
サインインしてコメントを残してください。