次の手順の前にAPIの変更操作を確認する

2xxレスポンスはルートが定められた仕様に従ってリクエストを受け付けたことを示します。ルート固有の読み取りは、次の手順で意図した状態を確認できることを示します。dosyaのX-D1-BookmarkはD1セッションの読み取りを順序付けますが、ファイルの内容はその順序付けの対象外であるワークスペースオブジェクトに存在する場合があります。

始める前に

• 変更操作を送信する前に事後条件を定義してください。正確なID、親、名前、削除状態、バージョン、バイト数などです。
• ルートの再送時の動作を確認してください。ワンショットアップロードには冪等性キーがありますが、フラグなしのファイルDELETEは2回目の呼び出しで完全な消去になる場合があります。
• 操作の受領情報としてステータスとレスポンス本文を保持してください。X-D1-Bookmarkがある場合は、後のD1を使う読み取りのために保持します。

手順

1. 対象を読み取り、現在のIDと状態を記録してください。古いローカルの想定に基づいて書き込みリクエストを送らないでください。
2. 範囲を絞った変更操作を1回送信してください。移動や名前変更の{ "ok": true, "name": "…" }、アップロードのファイル受領情報など、文書化されたステータスとフィールドを確認します。
3. レスポンスにX-D1-Bookmarkが含まれる場合は取得してください。次のリクエストに付けて、そのリクエストのD1セッションを順序付けます。ワークスペースオブジェクトとのストレージ間の順序は保証されません。
4. 変更操作に対応する確認の読み取りを行ってください。移動や名前変更後は同じIDを取得し、ゴミ箱への移動後は削除済み一覧を照会し、アップロード後は返されたファイルIDを取得します。
5. 読み取り結果を事前に定義した事後条件と比較してください。元の一覧が空であることを、項目が意図した新しい状態で存在する証拠の代わりにしないでください。
6. それに依存する次の操作の前に、変更操作の受領情報と確認済みの状態を保存してください。確認結果が不明な場合は、安全でない書き込みを再送せずに停止して調査します。

期待される結果

受領情報とルート固有の読み取りが同じ対象と確定済みの状態を示します。後続の自動処理は操作固有の事後条件を確認できてから開始します。ブックマークが役立つのは読み取りにD1を使う場合だけです。

トラブルシューティング

変更操作は成功したが読み取り結果が古い場合 次のリクエストが同じIDとワークスペースを対象にしているか確認してください。D1の状態にはレスポンスのブックマークを引き継ぎますが、ワークスペースオブジェクトの内容はルートのレスポンス自体から判断します。

レスポンスが失われた場合 まず読み取ってください。ルートの冪等性が文書化されている場合か、確認した事前条件から元のリクエストが確定しなかったと証明できる場合にのみ再送します。

元の場所が空の場合 移動先または削除済み一覧をIDで確認してください。存在しないことだけでは事後条件を満たした証拠として不十分です。

関連ガイド

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