Skip to main content
POST
snapshot の作成
各アカウントは 24 時間ごとに最大 (RAM / 256) * 2 回の snapshot を実行できます。
string
必須
アカウントの API キーです。これはアカウント設定で確認できます。
snapshot の作成は、アプリケーションのストレージ全体をある時点でキャプチャした .zip のコピーを生成し、署名付きダウンロード URL を返します。リスクのある変更を行う前の復元ポイントとして、またはプラットフォーム外にフルバックアップを持ち出す手段として利用できます。後でアプリケーションをその状態に戻すには、生成された snapshot をスナップショットの復元に渡してください。新しい snapshot を作成せずに過去の snapshot を確認・ダウンロードするには、スナップショット一覧の取得を使用してください。 snapshot は有料プランでのみ利用でき、1 日あたりのクォータはアプリケーションの RAM に応じて変動します((RAM / 256) × 2 回 / 24 時間)。ワークスペースで共有されているアプリケーションでは、呼び出し元に Administrator ロールが必要です。

パラメータ

string
必須
アプリケーションの ID。アプリケーションのダッシュボードの URL で確認できます。

ソフトデッドラインの挙動

このルートは ソフトデッドライン モデルに従います。つまり、常に同期的に応答するわけではなくなりました。
  • snapshot が 約 90 秒以内 に完了した場合、ルートは以前と同様に 200 success と署名付きダウンロード URL(30 日間有効)を返します。
  • snapshot の生成に 約 90 秒以上 かかる場合、ルートは 即座に 202 とコード SNAPSHOT_PROCESSING を返します。これは失敗ではありません。 snapshot はバックグラウンドで生成を続け、通常は約 2 分以内に自動的に snapshot 一覧 に表示されます。これは大規模なアプリケーションでは想定される挙動です。
この POST endpoint をポーリング手段として使用しないでください。SNAPSHOT_PROCESSING の snapshot が完了したかどうかを確認するには、別の POST ではなく snapshot 一覧の取得GET)endpoint を使用してください。snapshot 完了後に再度 POST すると、まったく新しい snapshot が最初から開始されます。
クライアントは、レスポンスに応じて以下のように分岐する必要があります。

レスポンス

string
呼び出しが成功したかどうかを示します。成功した場合は success、失敗した場合は error です。
object
レスポンスの内容。statussuccess の場合にのみ存在します。
202
snapshot が約 90 秒のソフトデッドラインを超えた場合に返されます。snapshot はバックグラウンドでまだ生成中で、通常は約 2 分以内に自動的に snapshot 一覧に表示されます。エラーではありません。待ってから GET の一覧 endpoint で確認してください。

エラー

snapshot リクエストは 429 Too Many Requests で拒否されることがあります。code フィールドを使って 2 つのケースを区別してください。
429
短期的なクールダウン。ユーザーごと(5 秒あたり 1 リクエスト)またはアプリケーションごと(180 秒あたり 1 リクエスト)の制限に達しました。少し待ってから再試行してください。
429
1 日あたりのクォータに達しました。アカウントがプランの 1 日あたりの snapshot 許容量(24 時間あたり (RAM / 256) × 2)を使い切りました。クォータはローリング 24 時間ウィンドウが進むにつれて解放されます。1 日あたりの許容量を増やすには、プランをアップグレードしてください。