APIでファイルをゴミ箱に移動する

自動処理で復元可能な削除を行う場合はDELETE /api/files/:id?trash_only=1を使用してください。この保護により繰り返し送信しても問題は起きません。フラグなしのDELETEの動作は状態に依存します。削除前のファイルはゴミ箱に移動し、既にゴミ箱にあるファイルは完全に消去します。

始める前に

• フルアクセスのAPIキーを使用してください。ワークスペースのロールには、呼び出し元のファイルの場合はdelete_own_files、他のオーナーのファイルの場合はdelete_any_fileが必要です。
• 削除前にファイルID、名前、バージョン数、現在の親を記録してください。
• 削除済みの項目は完全に消去するまでストレージを使用します。消去は取り消せません。

手順

1. 対象のメタデータを読み取り、IDが意図したワークスペースに属することを確認してください。既に削除済みの場合は、ジョブがその状態を明示的に扱う場合を除き停止します。
2. Bearerキーを使用してDELETE /api/files/file_id?trash_only=1を送信してください。permanent=1は含めないでください。2つのフラグを併用することはできません。
3. 最初のゴミ箱への移動では{ "ok": true, "permanent": false }を受け取ります。安全なリクエストを繰り返すと{ "ok": true, "already_trashed": true }が返る場合があります。
4. GET /api/files?deleted=1を照会し、同じIDを探してください。フィルターやページ分割でも項目が見えなくなるため、通常の一覧にないことだけでは十分な証拠になりません。
5. ゴミ箱への移動の受領情報をジョブの記録とともに保存してください。フラグなしの2回目のDELETEを一般的な再試行として送らないでください。サーバーはゴミ箱にある状態を消去の許可と解釈します。
6. 完全な削除が明示的に承認された場合はDELETE /api/files/file_id?permanent=1を送信し、削除済み一覧から消えたことを確認してください。この操作は取り消せず、すべてのバージョンを復元できません。

期待される結果

安全なリクエストは削除前のファイルをゴミ箱に移動し、繰り返すと消去せずにalready_trashedを返します。ストレージ使用量が減るのは、別途完全な削除をリクエストした後だけです。

トラブルシューティング

削除済み一覧にファイルがない場合 再試行する前にページ分割、ワークスペース、レスポンスのステータスを確認してください。

403が返る場合 キーのフルスコープ、オーナーの権限、ロックのルールを確認してください。

フラグなしのDELETEのレスポンスが失われた場合 次の呼び出しを行う前に通常の一覧と削除済み一覧の両方を確認してください。既にゴミ箱にある可能性がある項目に対してフラグなしで再試行しないでください。

関連ガイド

• フォルダー操作を使用する
• REST APIクイックスタート