中断したAPIアップロードを再開

dosyaは50 MiBを超えるとマルチパートアップロードを選択します。それ以下の空でないファイルでもforce_multipart: trueで指定できます。マルチパートセッションは10 MiBのパートを使用し、生のバイトオフセットではなくアップロード済みパート番号から再開します。

始める前に

• 完了するまでsession_id、元ファイル、宣言したfile_size、コンテンツハッシュがあればそれも保持します。
• 同じdosyaユーザーとワークスペースで、元のセッションと変更されていないファイルを使って再開します。認証情報は許可された代替APIキーでもかまいません。セッションの初期化に使用したキーである必要はありません。
• 未開始の保留中セッションは10分後にクリーンアップ対象となり、マルチパート作業はパートが届かないまま24時間経つと削除されることがあります。バケットの7日間のマルチパートライフサイクルは最後の安全策にすぎず、完了または失敗したセッションの行は7日後に削除されることがあります。保証された有効期限ではなく、ステータスを基準にしてください。

手順

1. GET /api/upload/session_id/statusを呼び出します。status、size_bytes、part_size、total_parts、bytes_uploaded、uploaded_parts、has_multipart、完了によって生成済みの場合はfile_idを読み取ります。
2. ステータスがすでに完了を示し、file_idがある場合は、追加でアップロードせずそのファイルを確認します。アクティブなセッションでは1からtotal_partsまでの不足する整数を計算します。
3. ローカルの元ファイルの(partNumber - 1) × part_sizeに移動し、不足する各パートのみPUT /api/upload/session_id/part/partNumberにアップロードします。最後のパートは10 MiBより短くてもかまいません。
4. パート再送の成功レスポンスにあるalready_uploaded: trueは重複ではなく確認として扱います。通信障害後はステータスを再確認してください。接続が切れる前にサーバーがパートを保存した可能性があります。
5. ステータスに予定された全パートが表示されてからPOST /api/upload/session_id/completeを送信します。Only N of M parts uploaded. Upload remaining parts before completing.が返された場合は不足パートの計算に戻ります。
6. 完了時の受領情報にファイルIDがあることを確認し、メタデータを取得して最終的な実測サイズまたは設定したハッシュを比較します。検証後にのみローカルの再開記録を削除します。

期待される結果

予定されたすべてのパート番号がステータスに表示され、完了時に保存済みファイルの受領情報が返されます。メタデータを読み取ると完成したオブジェクトが表示されます。記録済みパートを再送してもパートは重複しません。

トラブルシューティング

ステータスが存在しないか期限切れ。 古いセッションを再開できなくなったことを確認してから、新しいセッションを開始してください。

ローカルの元ファイルが変更された。 再開を中止してください。あるバイト列のパート番号を別のバイト列の完了に安全に使用することはできません。

完了時にパート不足が報告される。 uploaded_partsを基準に不足する番号のみアップロードし、再度完了を呼び出してください。bytes_uploadedをバイトオフセットによる再開として扱わないでください。

関連ガイド

• APIでアップロード
• REST APIクイックスタート