翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon EFS API は、HTTP (RFC 2616)
Amazon EFS API は RPC モデルです。このモデルでは、オペレーションの固定の設定があり、各オペレーションの構文は、事前に操作しなくてもクライアントに知られています。次のセクションでは、理論上の RPC 表記を使用する各 API オペレーションについて説明します。それぞれには、オンラインでは表示されないオペレーション名があります。各オペレーションでは、トピックが HTTP リクエスト要素のマッピングを指定します。
リクエストがマッピングされる特定のAmazon EFSオペレーションは、リクエストのメソッド(GET、PUT、POST、またはDELETE)と、Request-URIがマッチする様々なパターンの組み合わせによって決定されます。オペレーションが PUT または POST の場合、Amazon EFSは Request-URI パスセグメント、クエリ パラメータ、およびリクエストボディ内のJSON オブジェクトからコール引数を抽出します。
注記
などのオペレーション名はワイヤに表示されCreateFileSystem
ませんが、これらの名前は AWS Identity and Access Management (IAM) ポリシーで意味があります。詳細については、「Amazon EFS のためのアイデンティティとアクセス管理」を参照してください。
オペレーション名は、コマンドラインツールのコマンド名や AWS SDK API の要素にも使用されます。たとえば、 CreateFileSystem
オペレーションにマッピングcreate-file-system
される という名前の AWS CLI コマンドがあります。
オペレーション名は、Amazon EFS API コールの AWS CloudTrail ログにも表示されます。
API エンドポイント
API エンドポイントは、API コールのために HTTP URI でホストとして使用する DNS 名です。これらの API エンドポイントは に固有 AWS リージョン であり、次の形式を取ります。
elasticfilesystem.
aws-region
.amazonaws.com
たとえば、米国西部 (オレゴン) リージョンの Amazon EFS API エンドポイントは次のようになります。
elasticfilesystem.us-west-2.amazonaws.com
Amazon EFS がサポートする (ファイルシステムを作成および管理できる) AWS リージョンのリストについては、 のAmazon Elastic File System」を参照してくださいAWS 全般のリファレンス。
リージョン固有の API エンドポイントは、API コールを作成したときにアクセスできる Amazon EFS リソースの範囲を定義します。たとえば、前述のエンドポイントを使用して DescribeFileSystems
オペレーションをコールする際、アカウントに作成された 米国西部 (オレゴン) リージョン内のファイルシステムのリストが表示されます。
API バージョン
コールに使用される API のバージョンは、リクエスト URI の最初のパスセグメントにより特定されます。この形式は ISO 8601 の日付になります。例については、「CreateFileSystem」を参照してください。
ドキュメントでは、API バージョン 2015-02-01 について説明されています。
関連トピック
以下のセクションでは、API オペレーション、認証リクエスト用の署名を作成する方法、IAM ポリシーを使用して、これらの API オペレーションのためのアクセス許可を付与する方法を説明します。
Amazon EFS のクエリ API リクエスト率の使用
Amazon EFS API リクエストは AWS アカウント 、サービスのパフォーマンス向上に役立つように、リージョンごとにそれぞれ調整されます。すべての Amazon EFS API コールは、アプリケーション、、 AWS CLIまたは Amazon EFS コンソールから発信されるかどうかにかかわらず、許可される API リクエストの最大レートを超えてはなりません。API リクエストの最大レートは、 によって異なる場合があります AWS リージョン。行われた API リクエストは、基盤となる に属性付けられます AWS アカウント。
API リクエストがそのカテゴリの API リクエスト率を超過する場合、ThrottlingException
エラーコードが返されます。このエラーを回避するには、アプリケーションが API リクエストを再試行する率を低くします。これは、ポーリングの際に注意深くし、エクスポネンシャルバックオフの再試行を使用することにより行えます。
ポーリング
アプリケーションにより API オペレーションを繰り返しコールして、ステータスの更新をチェックする必要がある場合があります。ポーリングを開始する前に、リクエストの予想完了時間を指定します。ポーリングを開始するとき、連続するリクエストの間に適切なスリープ間隔を使用します。最良の結果を得るには、漸増スリープ間隔を使用します。
再試行またはバッチ処理
アプリケーションは、API リクエストが失敗した後に再試行するか、複数のリソースを処理する必要がある場合があります (たとえば、Amazon EFS ファイルシステムすべて)。API リクエストの率を下げるには、連続するリクエストの間に適切なスリープ間隔を使用します。最良の結果を得るには、漸増または可変スリープ間隔を使用します。
スリープ間隔の計算
API リクエストをポーリングまたは再試行する必要がある場合は、エクスポネンシャルバックオフ アルゴリズムを使用して API コール間のスリープ間隔を計算することをお勧めします。エクスポネンシャルバックオフの背後にある考え方は、連続したエラー応答の再試行間の待機時間を徐々に長く使用することです。詳細およびこのアルゴリズムの実装の例については、「Amazon Web Services 全般のリファレンス」の「AWSでのエラーの再試行とエクスポネンシャルバックオフ」を参照してください。