状態と操作を分離する

考え方

保存操作に状態変更を混ぜず、状態は状態として独立させる。

「下書き保存」と「確定保存」のように、保存ボタンが複数あるなら、設計を見直すきっかけかもしれません。

ユーザーのゴール達成にどう寄与するか: 「内容を直したい」と「状態を進めたい」を別々に実行できる。「柔軟に作業を進めたい」というゴールに直結する。

保存操作に状態変更を混ぜると、「状態を変えるためだけに編集モードにする」という不自然な操作が生じます。

保存と状態変更が混在

保存と状態変更が分離

PUT  /items/:id          → 内容を更新（状態は変えない）
PATCH /items/:id/status  → 状態のみ変更
POST /items/:id/submit   → 申請（状態遷移 + 副作用を伴う操作）

PUTは内容の更新、PATCHは部分的な変更（状態のみ）、POSTは副作用を伴う操作（通知送信など）という使い分けが一般的です。

状態を進めるには条件の満たされていることが必要です。

この場合でも、「保存」と「状態変更」は分けておくと、ユーザーは途中まで入力して保存し、後から続きを入力できます。

状態の意味によっては、属性更新に含めても破綻しにくい場合があります。

分類・ラベル程度で、業務上の意味が薄い場合（例：色ラベル、タグ的な公開/非公開、個人メモの分類）は、PUT や PATCH で内容と一緒に更新してもよいことがあります。ただし、UI の都合で「保存ボタンが複数」になっているなら、分離した方がよいです。
ライフサイクルの段階で、条件・権限・副作用の絡む場合（申請→承認、締め処理など）は、上で述べた通り「内容」と「状態」を別操作にするほうが適切です。

判断の目安として、「状態を変えるために編集モードを開く必要があるか」を考えると分けやすいです。編集画面を開かずに状態だけ変えられれば、分離できていると言えます。