下書き保存パターン

例：承認ワークフローシステム

申請を作成し、複数の承認者が順に確認・承認する。

適用する原則: 状態と操作を分離する

要件

• 作成途中で中断・再開したい
• 下書き状態では申請に進めない
• 承認は複数段階
• 監査・説明責任が強い

---

典型

典型パターン：下書き保存と保存が分離 別タブで開く ↗

GET    /petitions                  稟議一覧
GET    /petitions/:id              稟議詳細（編集モード含む）
PUT    /petitions/:id/draft        下書き保存（status = 下書き）
PUT    /petitions/:id/confirm      確定保存（status = 確定）
POST   /petitions/:id/submit       申請

起きる問題

稟議詳細の編集モードに2つのボタンがある：

• 下書き保存 → DB保存 + status = 下書き
• 確定保存 → DB保存 + status = 確定

「状態を変えるためだけに編集モードにする」 という不自然な操作が発生する。

「下書きかどうか」は状態であり、保存操作とは独立しているべき。

---

再設計

再設計パターン：保存と状態変更を分離 別タブで開く ↗

GET    /petitions               稟議一覧
GET    /petitions/:id           稟議詳細（編集モード含む）
PUT    /petitions/:id           更新（状態は変えない）
PATCH  /petitions/:id/status    状態変更（下書き ↔ 確定）
POST   /petitions/:id/submit    申請

設計のポイント

• 保存ボタンは1つだけ
• 「下書き/確定」は状態として稟議詳細で切り替え可能（ステータスバッジをクリック）
• 保存と状態変更を分離する

---

比較

観点	典型	再設計
保存ボタン	2つ（下書き保存/確定保存）	1つ（保存）
状態切替	編集モードで保存が必要	ステータスバッジから直接
PUT	2つ（/draft, /confirm）	1つ
status	保存操作に依存	状態として独立