リクエストのカウント方法
実行された各ルート操作フィールドが 1 回の API 呼び出しです。 4 つのルートフィールドを要求する GraphQL リクエストは、4 回の REST リクエストを行った場合とまったく同じく、4 回の API 呼び出しとして課金されます。ルートのエイリアスは、それぞれが操作をディスパッチするため個別にカウントされます。型付きレスポンスから選択したネストされたフィールドは、API 呼び出しを増やしません。- 既存のプランの制限はそのまま適用されます。プランの許容量については API の制限 を参照してください。
- 不要なルート操作を要求すると、REST で呼び出した場合と同じコストがかかります。必要なネストされたレスポンスフィールドを選択しても、呼び出し回数は増えません。
- リクエストは途中でレート制限される場合があります。完了したルートフィールドはデータを保持し、制限されたルートフィールドのみがエラーを返します。部分的な成功 を参照してください。
クエリの制限
エンドポイントは、クエリの形状とサイズにいくつかの制限を設けています。これらは、1 回のリクエストがこちらの処理能力を不当に消費できないようにするためのもので、通常の使用に必要な水準を大きく上回るように設定されています。制限に達している場合、それは通常、実際の必要性ではなく、誤って生成されたクエリの兆候です。
拒否されたクエリは、
Accept: application/graphql-response+json を送信した場合は HTTP 400 を、それ以外の場合は HTTP 200 を返し、いずれの場合も errors 配列を含み、data は含みません。エラーを参照してください。
リクエストあたりの API 呼び出し数
最も重要な制限です。1 回のリクエストで発生させられる API 呼び出しは最大 5 回であるため、上記の 4 つのルートフィールドの例は問題ありませんが、20 個のルートフィールドを持つリクエストは許可されません。5 回のディスパッチが開始されると、追加のルートフィールドは制限を説明する 429 を返します。すでにディスパッチされたフィールドは引き続きデータを返すことができます。 さらに必要な場合は、クエリを複数のリクエストに分割してください。正当なワークロードのためにそれを日常的に行っている場合は、お問い合わせください。この制限はリリース時点では意図的に控えめに設定されています。引き上げるのは簡単ですが、後から引き下げるとインテグレーションが壊れてしまうため、小さな値から始めています。深さ、フィールド、エイリアス
これらは何かが実行される前にチェックされるため、超過しても API 呼び出しは一切消費されません。 また、これらの制限は完全なイントロスペクションクエリ（約 180 フィールド、深さ 12 レベル、エイリアスなし）を十分に上回っているため、起動時にスキーマ全体を取得するクライアントも正常に動作します。リクエストボディのサイズ
64 KB です。クエリには十分な大きさですが、ファイルにはまったく足りません。これが、GraphQL でメディアをアップロードできない理由です。サポートされている方法については メディアのアップロード を参照してください。タイムアウト
リクエスト全体には最大 120 秒が与えられます。クエリのルートフィールドは並行して実行される場合があるため、その所要時間は通常、最も遅い依存先によって決まります。ミューテーションのルートフィールドは直列に実行されるため、遅いミューテーションが複数あるとタイムアウトに向けて時間が累積する可能性があります。どちらの形式でも、バックエンドには最大 5 回分の並行または順次のディスパッチに相当する負荷がかかる可能性があります。必要に応じて、遅いことがわかっている処理は分割してください。制限されないもの
- スキーマの読み取り。 イントロスペクションは認証不要で、計測もされません。何が存在するかの閲覧は無料ですが、操作の実行は無料ではありません。
- 不正なクエリ。 不明なフィールド、誤った型、無効な列挙値など、GraphQL が拒否するクエリは API に到達することはなく、課金されることもありません。